pfuentes69
Well-known member
Hi @slipperygrey
Do you keep embedding the latest builds of Netatalk in PISCSI?
Do you keep embedding the latest builds of Netatalk in PISCSI?
Yes netatalk 2.x works with any macOS version to date. Apple has thankfully kept the AFP client alive and backwards compatible so far.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.
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.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.
Yes I do!Hi @slipperygrey
Do you keep embedding the latest builds of Netatalk in PISCSI?
Thanks!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, I just updated pkgsrc net/netatalk22.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.
Interesting - if there have been any local changes to the netbsd-10 openssl 1.1, they went past me.@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
What worked for me in the end isThe workaround is to use randnum and clrtxt UAMs, while disabling DHX. Would this work for you?
-uamlist uams_clrtxt.so,uams_dhx2.so
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
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.txtI 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?
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.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.