AppleTalk daemon support in init scripts
Closed this issue · 4 comments
The main branch init scripts are currently designed to operate only the netatalk controller daemon.
We need to bring back init scripts for atalkd/papd/timelord/a2boot.
- openrc
- systemd
- netbsd rc
- debian sysv
The above are the relevant ones for platforms that have an AppleTalk network stack. I say we leave the other init styles as-is for now, and revisit if those platforms get a userland AppleTalk stack in the future.
Proposed naming convention:
[platform].[daemon].[filending].in
Platform can be the OS or the cross-platform init system, depending on its nature. Not all init scripts have file endings, but when they do let's indicate that in the template name.
Ex.
- solaris.netatalk.xml.in
- systemd.a2boot.service.in
- systemd.atalkd.service.in
- systemd.netatalk.service.in
- systemd.papd.service.in
- systemd.timelord.service.in
A special case is macOS launchd which has pairs of controller scripts and plist definitions. I'd just add "plist" to the soup.
Design note: I think the init scripts should be atomic, with a 1:1 daemon to init script correlation. I do not want to bring back the old-school netatalk.conf file that controls which daemons to start.
The NetBSD and systemd init scripts in 2.x are already designed in this way and can be forward-ported as-is. But the OpenRC and Debian sysv init scripts need to be rewritten.
Note on the openrc script: Let's rewrite it from scratch using Gentoo and Alpine guidelines, so that we can give it a proper GPLv2+ license grant.
https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts
https://wiki.gentoo.org/wiki/OpenRC
The only thing netatalk.conf had left in it was being able to set the ATALK_MAC_CHARSET and ATALK_UNIX_CHARSET environmental variables. The code to read these, along with trying to auto-detect and set the charset from LOCALE was removed in 3.x. Right now my porting work hard codes atalkd, papd, and getzones to use MAC_ROMAN encoding, with no option to change it.
This only affects the display of NBP objects and zones if they were set in another character encoding. I'm trying to find if this was even "legal" as Inside AppleTalk only mentions MacRoman encoding for NBP Entities in Appendix D. Right now, nbplkup and friends can be forced to display and register objects in other encodings with the -m switch.
@NJRoadfan This reminds me of this bug: #360