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

[cheesestraws]

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.

 

[mactjaap]

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

• TimeLord
  In 1990, the University of Melbourne built a pair of tools called Timelord. Netatalk ( heart of the MacIPRpi) has a version to. It never worked until revived by 68kmla.org forum member cheesestraws.
  Now on the MacIPRpi with a UTC and LocalTime version in your Chooser.
  
  credits to: cheesestraws,
  68kmla.org/bb/index.php?threads/doctorin-the-tardis-and-timelord-the-revived-appletalk-time-server.38553

 

[slipperygrey]

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]

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]

@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]

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]

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.

 

[cheesestraws]

Anyhow, please let me know if you track down that other piece of source code

Can you remind me in about a week? I'll be back home then, and my short term memory is appallingly bad at the moment so otherwise I am likely to forget

 

[slipperygrey]

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.

 

[cheesestraws]

I'll dig it out when I get home, no fret .

 

[cheesestraws]

I can't find the modified source. I remember it wasn't complicated.

 

[mactjaap]

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.

 

[cheesestraws]

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]

@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!

 

[slipperygrey]

@cheesestraws That's a bummer! Do you remember if you used localtime(), or some other API to get get the time zone data?

 

[cheesestraws]

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]

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]

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]

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

 

[cheesestraws]

That was it. I remember now. Thanks!