• 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.

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

cheesestraws

Well-known member

insert wibbly flashback effects here

"It would be nice to run my macs without a PRAM battery," you say, "but I like having the right time, and I am using LocalTalk."

Timelord and Tardis are your friends here. You can sync clocks over AppleTalk in a similar way as you would with NTP, but with much lower overhead; it'll run off a floppy with System 6. But the Timelord time server in netatalk2 has been broken for approximately ever. I have fixed this.

A question I get often, with regard to this and Force32: "do you have something against PRAM batteries?". Yes, yes, I do: it's personal.

insert even wibblier even more flashback effects here


In 1990 the University of Melbourne produced something for their Mac labs that would make sure that their user-facing Macs kept the right time, and they shared this with the world. This consisted of two bits: a chooser extension called Tardis, that allowed selection of a time server, and a CDEV called Timelord, which implemented that time server on another Mac (presumably a server).

A UNIX version of the time server was built into the Columbia AppleTalk Package; then rewritten totally for inclusion in netatalk. During this rewrite, it was totally broken on anything other than 32-bit big endian machines, and it stayed broken. (Technical details of what went wrong in another post below, probably).

insert wibbling the other way to denote a return to some approximation to the present

I fixed it. There, that's the story. Here are attached two files: the first, TARDIS.CPT.ZIP is a zip-compressed compact pro archive (to get around file name restrictions on the forum at the moment...) which is the original Tardis/Timelord distribution from the University of Melbourne (I do not recommend using the Timelord CDEV; I've never got the thing to work properly.)

timelord.zip is a patched version of the netatalk2 timelord server so it works. To build it, make sure you have netatalk2 installed and the normal build chain for your OS; edit build.sh and change the include and library paths for your specific OS (the default is for pkgsrc under NetBSD) and run ./build.sh.

You can copy the resulting executable on top of the one provided by netatalk2 and it will make it work, or you can do something more complicated. Your call.
 

Attachments

  • TARDIS.CPT.zip
    11.4 KB · Views: 16
  • timelord.zip
    6.6 KB · Views: 16

mactjaap

Well-known member
The 2021 Big Crash of the forum destroyed our conversation about this update. I would like to thanks cheesestraws again for reviving the AppleTalk Time Server!!

It is now included in the current MacIPRpi image. Read all about it on:
www.macip.net

 

slipperygrey

Well-known member
This is an awesome fix for timelord -- thank you cheesestraws! I've been successful in using it with bleeding edge Netatalk 2.2.x on a Raspbian Bullseye system. Special thanks to mactjaap for bringing the thread back from the grave!

The one challenge that I've run into is that the tv.tv_sec value we get back does not take time zone into consideration. Effectively, the datetime that the Tardis extension records is an accurate GMT datetime, and not the local time of the host running timelord.

Adding some debugging output to the code demonstrates that the problem seemingly is in the timezone struct, with both tz.tz_minuteswest and tz.tz_dsttime being set to '0' after gettimeofday() has run. The documentation indicates that gettimeofday() itself has been deprecated and the timezone struct nonfunctional, and that we should either move to clock_gettime() instead, or otherwise use localtime() to extract the accurate timezone by other means.

I've tried to play around with the code a bit but haven't gotten in to work yet, since my C skills are nonexistent.
 

cheesestraws

Well-known member
The one challenge that I've run into is that the tv.tv_sec value we get back does not take time zone into consideration. Effectively, the datetime that the Tardis extension records is an accurate GMT datetime, and not the local time of the host running timelord.

I have a version somewhere that does that, it sends the timelord host's local time not the GMT time. I'm not at home at the moment so I don't have access to it: I think both versions are on @mactjaap 's macippi, because ...

... it's not quite as simple as this, because how the Mac responds to getting the timestamp from timelord depends on how its timezone is set, and I think on what version of MacOS it is running. I can't remember the exact details but when @mactjaap and I talked it through before we couldn't either of us think of a neater solution than having two versions, one that sends out the time in local timezone and one in GMT.

@mactjaap — if you're about — do you happen to have the "other" timelord.c hanging about? Otherwise it will have to wait until I get home... Ideally this change should be behind a command line flag in timelord. I can't remember why I didn't do it like that. Probably ran out of time.

Unfortunately the source code for Tardis itself isn't, as far as I know, available, so can't be fiddled with to fix this "properly"
 

slipperygrey

Well-known member
@cheesestraws This makes a lot of sense, and I do know that different System Software / Mac OS versions have various interpretations of time zone. System 6 and earlier doesn't even have the concept of time zone, I believe. Just for the record: I did run a quick test on the systems that I have up right now (6.0.7, 7.1.1, and 8.6) the two latter having time zone set to PST which is the same as my host running timelord. All of them got assigned a GMT datetime interpreted as local time.

Anyhow, I do love the idea of having a runtime option for timelord for time zone handling! Then one could configure a systemd service for timelord with the right command line parameter for your particular network of classic Macs.

Full disclosure: I've been working on my own fork of Netatalk that takes in the last 5 years worth of community patches for 2.2.x plus some of my own fixes and additions.. My primary motivation for forking was to pull together the best version to serve as an integrated companion app to RaSCSI. Would you be comfortable with me taking in your timelord fixes into my fork?
 

cheesestraws

Well-known member
Anyhow, I do love the idea of having a runtime option for timelord for time zone handling! Then one could configure a systemd service for timelord with the right command line parameter for your particular network of classic Macs.

Yup, I think that's how it ought to be done. I must have just run out of time to spend on the project, I think...

Would you be comfortable with me taking in your timelord fixes into my fork?

That's a helpful thing to be doing!

Please by all means do :). In case you are unaware—I believe that the person maintaining the NetBSD pkgsrc package for netatalk2 is active and on the hunt for patches/fixes (or was last year—I haven't seen them around since the forum crash), so it might be worth comparing notes with them.
 

slipperygrey

Well-known member
That's a helpful thing to be doing!

Please by all means do :). In case you are unaware—I believe that the person maintaining the NetBSD pkgsrc package for netatalk2 is active and on the hunt for patches/fixes (or was last year—I haven't seen them around since the forum crash), so it might be worth comparing notes with them.

Here is the timelord-revived branch! It is also merged into the main work branch for convenience and testing.

And yes, I did notice that the NetBSD community has been keeping Netatalk 2.2 alive, and their patch repository has been an invaluable source for my project.

Anyhow, please let me know if you track down that other piece of source code. I've been trying to find a timelord.c in the one MacIPRpi image I've been able to access so far (MacIPgw-VM 3.1) but couldn't find any source code on that one.
 

slipperygrey

Well-known member
On the MacIPRpi 5.02 image file system, I found traces that you indeed ended up with two separate binaries for GTC and time zone sensitive timelord!

Unfortunately, the source code is nowhere to be found on the file system, or on the macip.net website.

@mactjaap when you see this, please help us track down the source code! And as a piece of friendly advice, it's always a good idea to proactively include source code with any binaries that you distribute. This is the spirit (and requirement) of open source software, after all. ;)
 

Attachments

  • IMG_4487.jpg
    IMG_4487.jpg
    2.8 MB · Views: 18

mactjaap

Well-known member
I'm running the MacIPRpi now of my latest image 5.02. So no traces of the settings to get it running in localtime. Same as slipperygrey found out.
But......I have the development image! I will have a look on that one to see what I have changed on cheesestraws code to get the localtime.
Cheesestraws and I talked about this setting in the ....lost ...post.... So I'm also not sure what it was. But I will do some digging.


@slipperygrey Just to be sure. I do link on macip.net to this post. In this post people can find cheesestraws code and Tradis. So anyone can download his modified code and play around with it.
 

Attachments

  • WhatsApp Image 2022-01-10 at 23.26.27.jpeg
    WhatsApp Image 2022-01-10 at 23.26.27.jpeg
    32.9 KB · Views: 14

cheesestraws

Well-known member
Yeah, it's not your fault it went walkies, it was in the previous iteration of this thread. I thought I had it locally too but I can't find it. It was a very small change, I remember that much.
 

slipperygrey

Well-known member
@mactjaap Yeah, I see your intention here. My point was that code loves to live in revision control systems, such as, say, your GitHub repo. Makes it so much easier for others to find, while keeping it safe for posterity! :)
 

cheesestraws

Well-known member
My point was that code loves to live in revision control systems, such as, say, your GitHub repo

I mean, really, that's my fault rather than @mactjaap's. I'm sure there was a reason I didn't put it on github, but it was probably a bad reason.

Do you remember if you used localtime(), or some other API to get get the time zone data?

I think I just used localtime, but I have a vague memory I had to manually offset something. Perhaps I'm wrong. My memory isn't good.
 

mactjaap

Well-known member
I mean, really, that's my fault rather than @mactjaap's. I'm sure there was a reason I didn't put it on github, but it was probably a bad reason.



I think I just used localtime, but I have a vague memory I had to manually offset something. Perhaps I'm wrong. My memory isn't good.
I will have a look tonight (GMT+1).
It must be on my development image!
 

NJRoadfan

Well-known member
It's too bad the Tardis CDEV doesn't handle the timezone thing correctly. One workaround with the Timelord server is to have it create two instances on the network by default. One for UTC and one for server local time.
 

mactjaap

Well-known member
Found it!!

I compiled it within the netatalk2.2.6 source, so just copied cheesestraws timelord.c over the original.
If I do a diff -u between the timelord.c cheesestraws made and the changes for localtime I see this:

macipgw@macippi: diff -u timelord/timelord.c localtime/timelord.c --- timelord/timelord.c 2021-06-03 23:37:17.000000000 +0200 +++ localtime/timelord.c 2022-01-11 22:25:08.053329255 +0100 @@ -227,12 +227,11 @@ LOG(log_error, logtype_default, "main: gettimeofday: %s", strerror( errno ) ); exit( 1 ); } - if (( tm = gmtime( &tv.tv_sec )) == 0 ) { + if (( tm = localtime( &tv.tv_sec )) == 0 ) { perror( "localtime" ); exit( 1 ); } - - mtime = tv.tv_sec + EPOCH; + mtime = tv.tv_sec + EPOCH + tm->tm_gmtoff; mtime = htonl( mtime ); resp = htonl( TL_OK );

I will upload both files for convenience
 

Attachments

  • timelord.c.txt
    5.9 KB · Views: 3
  • timelord.localtime.c.txt
    5.9 KB · Views: 2
Last edited:
Top