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

Netatalk 2.2.9 Released

slipperygrey

Well-known member
If I simply replace Netatalk 3.x on the NAS with Netatalk 2.x that would be work with macOS 12-13? The only Apple-specific feature I would like to keep (other than overall file sharing) is Time Machine for the Mac OS X - macOS machines.
Yes netatalk 2.x works with any macOS version to date. Apple has thankfully kept the AFP client alive and backwards compatible so far.

One key difference is that netatalk 2.x is compliant with the AFP spec up through 3.3, while netatalk 3.x is compliant with AFP 3.4. The only difference between the two AFP revisions is a more granular handling of a single POSIX error code in the later one.


If I was going to replace Netatalk 3.x with 2.x on the NAS, would it work to simply remove all of the Mac resource files from 3.x before switching to 2.x? That's pretty easy to do with a script.
Well, they won't do any harm per se, since EA metadata are all dot files that are ignored by netatalk 2.x anyways (unless you configure it to share dot files). Up to you if you want to remove them or not.
 
Last edited:

slipperygrey

Well-known member
Hi @slipperygrey
Do you keep embedding the latest builds of Netatalk in PISCSI?
Yes I do!

Or to be specific: I ship a script with piscsi that builds the latest version of my own netatalk fork. At some point I plan to switch over to upstream netatalk 2.2.x proper. Probably as soon as I figure out how to make a deb package and publish it somewhere.
 

pfuentes69

Well-known member
Yes I do!

Or to be specific: I ship a script with piscsi that builds the latest version of my own netatalk fork. At some point I plan to switch over to upstream netatalk 2.2.x proper. Probably as soon as I figure out how to make a deb package and publish it somewhere.
Thanks!
 

slipperygrey

Well-known member
I wanted to leave this note that I'm not planning to announce dot releases of Netatalk in these forums anymore, unless there's a new killer feature that got added, or something. :)

There is a new 2.2.10 release available over at GitHub, which I tagged a few days ago. It consists of a handful of incremental improvements and upgrading is recommended if you're running an earlier 2.2.x version.

However, this release is a stepping stone for one thing that I've been working on recently: Debian deb packaging for netatalk2. I spent the last week getting a Debian dev environment set up and familiarizing myself with debuild and dpkg. If someone would like to test a package shoot me a message -- I have my own home made debs for Bullseye and Bookworm locally that *should* work everywhere.

In the long run my goal, as I think I've mentioned elsewhere, is to get netatalk2 reintroduced at least into Debian unstable (Sid) repos.
 

slipperygrey

Well-known member
For all of you who are actively using netatalk today, please head over to this poll and tell us which OS you're running it on!

We'd love to know more about your particular environment and challenges. This helps us prioritize feature development, testing, and bug fixes in the future.
 

hauke

Active member
There is a new 2.2.10 release available over at GitHub, which I tagged a few days ago. It consists of a handful of incremental improvements and upgrading is recommended if you're running an earlier 2.2.x version.
Thanks, I just updated pkgsrc net/netatalk22.

An issue that I noticed recently: It looks like openssl 1.1 (on NetBSD 10, at least) has deprecated either algorithms or ciphers to the point where a System 9 client will not be able to set up an encrypted connection.

When I disable all UAMs for afpd, OTOH, MacOS X clients (10.13 here) will refuse to connect, because they will not work over an insecure link. Kind of a fix.

Have you seen this, and what would you suggest?
 

slipperygrey

Well-known member
@hauke Oh interesting, so the NetBSD folks must have backported the key length mandates from openssl3 to openssl1? In openssl3 at least the news is that 128 bit long keys in DHX / DHCAST128 are now considered insecure and not allowed. Too bad for OS9 and early OSX. See the discussion in https://github.com/Netatalk/netatalk/issues/358

The workaround is to use randnum and clrtxt UAMs, while disabling DHX. Would this work for you?

Other potentials options include linking with libressl or wolfssl which still support 128 bit keys, AFAIK.
 

hauke

Active member
@hauke Oh interesting, so the NetBSD folks must have backported the key length mandates from openssl3 to openssl1? In openssl3 at least the news is that 128 bit long keys in DHX / DHCAST128 are now considered insecure and not allowed. Too bad for OS9 and early OSX. See the discussion in https://github.com/Netatalk/netatalk/issues/358
Interesting - if there have been any local changes to the netbsd-10 openssl 1.1, they went past me.
The workaround is to use randnum and clrtxt UAMs, while disabling DHX. Would this work for you?
What worked for me in the end is

Code:
-uamlist uams_clrtxt.so,uams_dhx2.so

which allows Mac OS X 10.13 to create an encrypted connection, while System 7-9 Macs will use plain text authentication. Since this is a local LAN, that's fine with me.
 

slipperygrey

Well-known member
This is usually the UAM combination that I use as well.

You do have the randnum UAM that still works fine with the latest openssl and has 56 bits encryption (very weak) but is at least a step up from clrtxt. The drawback is that you have to use afppasswd to manage users and passwords which is a bit of a pain.
 

CTB

Well-known member
I just did a fresh install of Netatalk 2.2.10 on my Pi4. I can't find a thread on 2.2.10 so this seemed to be the next most active thread that is on topic. I have it successfully running apart from one issue that I probably an edge case. I can't get and Apple IIe to either boot or successfully log on to the server. I can log on from Macs via DDP or TCP and I can boot and log on from a IIgs. I get a wrong password error even though I have just used the same password with the Mac and logged in fine. The password I am using is the root passwords for the Pi.
 

Attachments

  • IMG_8514.jpeg
    IMG_8514.jpeg
    1.3 MB · Views: 14

NJRoadfan

Well-known member
Other users here have reported this problem. I am unable to test netbooting 8-bit machines (IIe with Workstation or the LC IIe card) since I don't have any on hand (Just ROM 01 IIgs and emulated ROM 3). According to Ivan's notes, you HAVE to log in as a guest if booting into ProDOS 8.
 

CTB

Well-known member
Tried that. Guest login gives an even more bizarre error.
Surprisingly my Ivanx original install of A2SERVER works fine with registered user and guest login from the same machine.
 

Attachments

  • IMG_8524.jpeg
    IMG_8524.jpeg
    899 KB · Views: 13
  • IMG_8517.jpeg
    IMG_8517.jpeg
    1.4 MB · Views: 14

slipperygrey

Well-known member
I think A2SERVER adds a bunch of Apple II specific settings to AppleVolumes.default. Here's a snippet where casefolding is set in A2SERVER's setup script.

Code:
    sudo sed -i 's/casefold:toupper //' /usr/local/etc/netatalk/AppleVolumes.default 2> /dev/null
    sudo sed -i 's/^VOLCASEFOLD:.*/VOLCASEFOLD:/' /srv/A2SERVER/.a2files/.appledesktop/.volinfo 2> /dev/null
    sudo sed -i 's|/media/A2SHARED/A2FILES|/srv/A2SERVER/A2FILES|' /srv/A2SERVER/.a2files/.appledesktop/.volinfo 2> /dev/null

Not sure if this would resolve your error though. My IIe doesn't have a network card.
 

CTB

Well-known member
I know a little bit of Linux, only enough to be dangerous. If I type these commands will they be added to AppleVolumes.default or do I need to add them manually?
 

slipperygrey

Well-known member
I know a little bit of Linux, only enough to be dangerous. If I type these commands will they be added to AppleVolumes.default or do I need to add them manually?
No you would be missing several earlier steps in the setup script. This is the one I am talking about https://github.com/RasppleII/a2server/blob/master/scripts/a2server-3-sharing.txt

If you don't want to mess around with the config files, I know for a fact that a refreshed a2boot release is in the works.
 

NJRoadfan

Well-known member
That is an OLD install. The old ones setup two shares. The A2FILES share was stuck with uppercase only files and existed to work with ProDOS 8 and net booting. There is a GSFILES share that had mixed case files.

Newer versions of A2SERVER uses ciopfs to convert the A2FILES shared directory to being case insensitive on the Linux side to avoid this problem. In theory you could do this with ext4 filesystems and newer kernels, but I haven't looked into it.

The "wrong password" error is likely because random number authentication UAM is setup, but the password file wasn't updated with the afppasswd utility.
 

NJRoadfan

Well-known member
OK, played with this more. Its likely the ATINIT file is missing from whatever user you are trying to login as. Check the USERS folder in the router directory of your AFP Share, there should be a folder named for your username with a folder called SETUP, this is where the ATINIT is.

Full path: AFPShareName/USERS/username/SETUP/ATINIT

Guest users have their ATINIT in the <ANY USER> folder.

Full path: AFPShareName/USERS/<ANY USER>/SETUP/ATINIT

Note that netatalk does NOT setup any of this and does not have the capability of building ATINIT files. All that is done by A2SERVER's netboot setup scripts. If using A2SERVER, by default, only the guest user can boot into BASIC.SYSTEM as the default "user1" login's ATINIT is set to load the Apple IIgs Finder.
 

CTB

Well-known member
That is an OLD install. The old ones setup two shares. The A2FILES share was stuck with uppercase only files and existed to work with ProDOS 8 and net booting. There is a GSFILES share that had mixed case files.

Newer versions of A2SERVER uses ciopfs to convert the A2FILES shared directory to being case insensitive on the Linux side to avoid this problem. In theory you could do this with ext4 filesystems and newer kernels, but I haven't looked into it.

The "wrong password" error is likely because random number authentication UAM is setup, but the password file wasn't updated with the afppasswd utility.
Can you please elaborate on where this is "Full path: AFPShareName/USERS/username/SETUP/ATINIT". I can't find it. On my original A2SERVER setup I assume that AFPShareName is A2SERVER but I can't find it anywhere.
 
Top