@Mk.558 Thanks for sharing your notes, as always! First a caveat: I've never used Mint. Wikipedia suggests that it's based on Ubuntu, so I am going to assume that it behaves the same.
In the list of prerequistes and dependencies, is libgcrypt supposed to be libgcrypt20?
In Debian and Ubuntu package repos, libgcrypt is an alias (virtual package) for libgcrypt20. Either one should work. I don't know if it's bad practice to use the virtual package?
The requirements on the main page, building from source page (of course different distros different requirements etc) and the README.md are all different. There is a requirement for the UnicodeData.txt, but no suggestion where to get it. I found it by digging through the unicode-org github file repository. Not sure where it should go...if I put it in /home/, then if another user logs in, he's got no access. Not in /var/, not in /srv/, ...
The best docs on this I have right now is under the Dependency Changes section in the 4.0.0 release notes:
Netatalk 4.0.0 is available! The Netatalk team is proud to announce the first release in the Netatalk 4.0 release series. This release constitutes major changes over Netatalk 3.2, and is recommende...
github.com
But as you point out, this information didn't make into the manual. I'll make improvements to the docs in the next release!
The master copy of UnicodeData.txt is at:
https://www.unicode.org/Public/UNIDATA/UnicodeData.txt
The easiest way to use it, is putting a copy into into the root of the Netatalk source dir. The build system should pick it up automatically. It is only a compile time dependency, not a run time dependency, so only the user that builds the software needs access.
The text in the compile page here --
https://netatalk.io/stable/htmldocs/compile is all stacked with escape characters that means it's hard to change something if you want to. It's a tough call because it makes it easier to read by a human, but ...
You mean the line break backslashes, right? The reason we do it like that is mostly to make it easier for us to edit and manage the sources in git. One idea I have right now is to do a regex search and replace when converting the yaml to xml to strip out the escape characters, then apply
white-space: pre-wrap; style to the <pre> element to force line wrapping... But I'm just thinking out loud now. Let me tinker with it and see if I can make it look better.
Appears that a $ sudo is missing on $ meson install -C build
This is because these steps double as the continuous integration script. The particular GitHub runner in this case has only a root user, and no sudo command installed.
I'm curious about the DocBook choice. I decided to skip on DocBook to see what I could use Netatalk for what I'm looking for without instaling a large list of other stuff. Turns out that was a bad call because without it, the man pages don't get installed. It looks like DocBook can be used to export XML formatted files into PDF, HTML, man page format, or something else. I guess I'm confused: normal man pages work fine for this implementation in my opinion.
The Netatalk man pages were always generated from DocBook XML, since at least 2004 and maybe earlier. However before v4.0 there were canned troff pages under revision control that the maintainers kept up to date manually. I did away with that in v4.0 as an effect of moving fully to Meson (and to reduce manual labor overhead for every release.) This also removes the risk of shipping outdated or broken troff pages (which had happened in the past...)
As I alluded to in an earlier thread, I'm looking into moving to another source format for documentation. The whole XML toolchain is extremely large and cumbersome.
The log feature in afp.conf doesn't seem to work. Using the webmin on a 4.0.1 installation, I used the webmin to try to figure out the syntax, and using /var/log/, a file named netatalk in the field and choosing /var/log/netatalk.txt -- none of them worked in the webmin. Of course it works fine to dump to /var/log/syslog, but with regular use of Netatalk and other stuff on the same system I think that would be a bad idea.
Can you please share what you have on logging in your afp.conf?
This is what I usually set:
[Global]
log level = default:debug
log file = /var/log/netatalk.log
I scoured the web for an example NAT configuration text file of any kind so I could try and make sense of it, but only found the that @NJRoadfan put up on his A2SERVER fork. It looks like this:
https://github.com/NJRoadfan/a2server/blob/currentdev/files/macipgw-start.sh.txt
Copying that file out into a text file, making it executable, starting atalkd, then netatalk, then running that script seemed to be OK? If I use MacTCP, the Fetch says it gets an illegal PORT command from the 10.4 FTP server and aborts the connection. Remote FTP servers don't work at all. OpenTransport also doesn't work at all. Here's the VM at work:
Did you read through
https://github.com/Netatalk/netatalk/wiki/MacIP-Gateway ?
I wonder if your Mint OS is using a too old Linux kernel that still does the DDP filtering crap?
FWIW, I could only demonstrate macipgw tunneling on a bleeding edge Debian Trixie (Testing) and not on stable Debian Bookworm. I think you need a very recent Linux kernel with all of the recent appletalk patches, i.e. at least v6.7 or later, v6.9 or later recommended.
