Need an "I don't know jack" guide to Pi 3 and Netatalk/CUPS

[Trash80toHP_Mini]

You could also try my stable or beta MacIPRPi image for RPI. Version 5.02 runs anyway on a RPI 3.

www.macip.net

Just put it on a SD card and go.

Knowing < jack, I'm curious about your image. Is it set up with Mac emulation as shown? If so, what System is up and running out of the box?

Installing I/O Board/Compute Module 4 in a dead Duo 280, not so worried about networking. If not, are there any images with Mac emulation/Linux ready to go out of the box?

 

[theirongiant]

Thanks. I'd tried that earlier and it wrote the following:

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

The error "bad termcap entry" shows up in many searches relating to things other than PAPD. The phrase "bad papcap entry" links to just two comments on an old distribution list talking about netatalk and papd.

EDIT: OH MY GOD I FIGURED IT OUT.

There was an unseen "tab" character on what I thought was a blank line.

Apparently, papd strictly interprets this as part of a configuration command. Geez... I wonder if

See screenshot below. (note: the previews might not work, but clicking the image will reveal it full size)

Once the offending tab was removed, the service started correctly, and other misconfiguration became crystal clear. I was able to get this working less than 5 minutes later. Since I had previously enabled the netatalk and papd services using systemctl, they both started automatically after rebooting the Raspberry Pi.

Update: and I have successfully printed a letterhead from "The Print Shop" on my Macintosh SE via LocalTalk PhoneNET adapters!

Here is the configuration that ultimately worked for me. I commented out the cups auto-add in order to define the printer with a custom name. "pr" appears to expect the short name of the CUPS queue. In my case, I named it "brother-hl-l2380dw."

~$ cat /etc/netatalk/papd.conf
# PAP print server daemon configuration (Netatalk 4.x)
#
# See the `papd.conf' manual page for examples.

# Uncomment the following line to share all CUPS enabled printers.
#cupsautoadd@68kradio.ddns.net:op=root:

O Brother Where Art Thou:\
    :pr=brother-hl-l2380dw:\
    :pd=/etc/cups/ppd/brother-hl-l2380dw.ppd:\
    :op=root:

Sometimes I wish documentation made this a little clearer in the examples (For instance: who actually calls their printer queue name "ps" ? This is easily confused with "postscript").

 

[NJRoadfan]

That would do it. The parsing of papd.conf is based on ancient code that was used to parse printcap files back in the day. They used the same formatting to ease administration in the pre-CUPS age.

Note, I don't think you actually need to specify a PPD file for CUPS printer queues. They are automatically generated by papd now (one thing I fixed in preparation of CUPS 3.0).

 

[theirongiant]

That would do it. The parsing of papd.conf is based on ancient code that was used to parse printcap files back in the day. They used the same formatting to ease administration in the pre-CUPS age.

Note, I don't think you actually need to specify a PPD file for CUPS printer queues. They are automatically generated by papd now (one thing I fixed in preparation of CUPS 3.0).

The auto-generated name combines the printer description and the hostname. In my case, that was "O Brother Where Art Thou pihole" which was too long. In the Chooser window, this caused the text to be compressed.

Does papd truncate print queue names to 31 characters? They have to be short enough for Chooser to create local queue files on the Desktop.

 

[theirongiant]

Update: yes, I have determined that papd fails to start if the printer name is longer than 31 characters. At least in this case it gives a somewhat-helpful error that the printer could not be published.

I'm going to file an issue on the netatalk github describing the unusual behavior, and ask them to document the requirement that the papd.conf file must not contain any lines beginning with white space characters (if this is indeed an insurmountable problem). Otherwise, see if it's possible to get papd to perform error-checking on the config file and log more descriptive errors.

 

[NJRoadfan]

Manually specifying the printer name via papd.conf circumvents the name mangling and truncation that the CUPS support does automatically via cupsautoadd. Basically, if your CUPS queue had that long name already, papd would have cut it off at 31 characters.

 

[theirongiant]

Well, that was quick. I got a response from the developer already:

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.

 

[slipperygrey]

Well, that was quick. I got a response from the developer already:

This developer is I. Haha.

@NJRoadfan and I discussed this topic a few months ago when working towards the v4 release. We didn’t have a concrete reason to change it at the time. But the use case at hand is a fair reason.

No promises, but I’ll tinker with this and see how feasible it is to migrate to iniparser.

 

[theirongiant]

This developer is I. Haha.

@NJRoadfan and I discussed this topic a few months ago when working towards the v4 release. We didn’t have a concrete reason to change it at the time. But the use case at hand is a fair reason.

No promises, but I’ll tinker with this and see how feasible it is to migrate to iniparser.

I appreciate this! Thanks!

Even if it's a breaking change, it's a good one.

I wonder if these guys ever figured out what was wrong with their papd.conf file 25 years ago.

 

[mactjaap]

Knowing < jack, I'm curious about your image. Is it set up with Mac emulation as shown? If so, what System is up and running out of the box?

Installing I/O Board/Compute Module 4 in a dead Duo 280, not so worried about networking. If not, are there any images with Mac emulation/Linux ready to go out of the box?

Ah. You mean this picture?

No ... not included. This is just how a telnet login looks to the MacIPRpi and a browser window. Just to show you can use MacIP over AppleTalk. My settings are these:


172.16.2.1 is the MacIPRpi with Netatalk and macipgw running on it.

( printing is now also enabled by default in the latest beta.)

 

[Durosity]

I’m curious.. I know this can be used to print from old Macs to new printers… but is there any functionality to print from new Macs to old printers? I have a ImageWriter LQ with the LocalTalk card and it would be pretty funky if I could print to it from my MacBook or iPhone!

 

[NJRoadfan]

Yes, you can using the PAP backend for CUPS, which now ships with Netatalk. The biggest limitation with ImageWriters is that they only have black and white support, but a color driver is in the works.

 

[Durosity]

Yes, you can using the PAP backend for CUPS, which now ships with Netatalk. The biggest limitation with ImageWriters is that they only have black and white support, but a color driver is in the works.

Interesting! I’ll keep an eye on that, as I only have a colour ribbon for my LQ (I picked up a box of 6 of them individually sealed BNIB and it seems to work perfectly) .. looking at it I’m guessing it needs to be directly connected to the Pi Rather than via the LocalTalk option?

 

[slipperygrey]

Interesting! I’ll keep an eye on that, as I only have a colour ribbon for my LQ (I picked up a box of 6 of them individually sealed BNIB and it seems to work perfectly) .. looking at it I’m guessing it needs to be directly connected to the Pi Rather than via the LocalTalk option?

Do you already have a bridge between your LocalTalk and Ethernet networks (where the RPi sits)? If so, connecting your ImageWriter to the LocalTalk network should be enough to make it accessible from the RPi that's running netatalk / pap.

Note that in general, you want to avoid routing AppleTalk traffic over WiFi.

 

[Durosity]

Do you already have a bridge between your LocalTalk and Ethernet networks (where the RPi sits)

Yep, it’s connected to my LocalTalk network which in turn is connected to a Daynaport Ethernet to LocalTalk bridge which in turn is connected to an airport extreme’s gigabit Ethernet port, and the Pi 4 is connected to one of the other ports.. AppleTalk traffic works fine over it so I imagine it should be fine with this too.

Ooh this is exciting.. although I’ll undoubtedly get stuck trying to get it setup so expect questions in the near future

 

[adespoton]

If you're using systemd, you don't get your informative output from syslog; you get it from journalctl. This exposes more information than what makes it into the syslog.

How To Use Journalctl to View and Manipulate Systemd Logs | DigitalOcean

Some of the most compelling advantages of systemd are those involved with process and system logging. Using other systems, logs are usually dispersed through…

www.digitalocean.com