papd cryptically fails to start if papd.conf contains lines starting with white spaces (or other unexpected characters)

[bradtchapman]

Describe the bug
When any line of papd.conf contains a white space character (Tab, Space), the papd service fails to start and writes unclear errors and failures to syslog. Running papd -d yielded cryptic messages like Bad termcap entry and Bad papcap entry.

After some head-scratching and double-checking the configuration file, I found a stray [Tab] character at the beginning of a line near the end of the file. Removing the [Tab] character allowed papd to start normally.

I consider this a bug because papd does not produce any useful error message, and the requirement to check for white space characters is not documented. The misconfigured papd.conf file produces what is essentially an uncaught exception, and gives the admin no insight as to what is wrong. I fixed this purely by accidental discovery.

To Reproduce

1. Open the papd.conffile.
2. On any empty line, insert a [tab] character or a blank space.
3. Save the file.
4. (Re)start the papd service (using your default service manager).
5. There will be some general error messages in the system log about a failure to start.
6. Now run papd -d in a console window.
7. Note the 'bad termcap entry' and 'bad papcap entry' errors as noted above.
8. Edit the papd.conf file to remove the offending characters.
9. Start the papd service. It should start normally.

Expected behavior (clear and concise description of what you expected to happen)
Speaking generally about most Linux-based daemons and services that rely on text configuration files, they don't care about extraneous white space characters at the beginning of lines. They're only looking for key-value pairs in statements like "variable = value."

I'm participating in the #Globaltalk network (part of the #Marchintosh vintage computer festival) and was absolutely pulling my hair out last night trying to figure out why papd would not start on my Raspberry Pi. After initial setup of papd with cupsautoadd:op=root: as the only option, the rest of my AppleTalk network could see the print queue in Chooser. However, I did not like the default format of the advertised printer name: "[Description] [Hostname]" and so I wanted to customize it a bit. That's when papd failed to start.

I was expecting papd to tell me what was wrong with my configuration file. I read and re-read the documentation and triple-checked my configuration, and could not find anything obvious. When a printer is actually misconfigured, the daemon gives somewhat useful errors i.e.: the queue can't be published (AppleTalk name is over 31 characters), or the lpd queue name doesn't exist (mismatch / mistyped / etc.).

While I don't intend to revive the ancient debate of tabs vs. spaces—sorry, but tabs are more efficient and consistent; spaces are for smoothbrains—the documentation nevertheless makes liberal use of white space characters in the man pages to illustrate the proper configuration of custom AppleTalk print queues. It is entirely possible for an admin to accidentally strike the [Tab] key or the [Space] key on a blank line, and accidentally leave one behind without noticing. It is not possible to see white-space characters in a Terminal window or a text editor unless the file undergoes a painstaking manual review, or if one is using a non-default text editor with non-default options to show unprintable characters.

Please update the documentation and/or the binary to check for formatting issues like this, and alert the admin. Thanks.

Environment

• Server OS: Debian Linux 12.9 (Raspberry Pi / Raspbian OS)
• Client OS : irrelevant
• Netatalk Version : 4.2.0dev

Logs
While running papd -d

papd: Set syslog logging to level: debug
papd: restart (4.2.0dev)
papd: CUPS support enabled (2.4)
Bad termcap entry
Bad papcap entry

papd-syslog-pihole-debian12_9.log

[rdmark]

Thanks for reporting this issue.

My immediate thought here is to rewrite the papd.conf parsing code to use the iniparser library instead of the arcane 30-year-old parsing logic we have now. The iniparser library would take care of all error handling for us. This would obviously fundamentally change the format of this config file to that of a standard ini file, akin to afp.conf.

A few theoretical examples for illustration.

[Printer Spooler]
printer name = Mac Printer Spooler
print command = ps
ppd file = /usr/share/lib/ppd/HPLJ_4M.PPD
operator = mcs

[Global]
cups autoadd = yes
zone = 1st floor
operator = root

[LaserWriter]
printer name = Boss' LaserWriter
zone = 2nd floor
print command = laserwriter-chief