Re: [PLUG] Parallel port with Debian 12

I know a lot of businesses use unsupported legacy software but Window server 2008 sounds scary for a production system. This is long out of date and dangerous to run in production. I realize this is a Linux group but I couldn't help but say this for starters. I don't think you can write to the parallel port with bash directly. I have had a little bit of experience playing around with an arduino, I tried unsuccessfully to turn it into a web server and it required C programming which I am a rank novice at. I think that writing to the parallel port is just like the arduino, you have to use a compiled language and have some knowledge of how drivers work. I could not get my arduino web server working because I could not successfully write a driver for the attached storage. I agree that CUPS has bloat but you will find that Debian has alternatives. If you don't want to write a driver in C this looks very promising:

https://unix.stackexchange.com/questions/18284/is-there-an-alternative-to-cups

Peace,

Michael Lazin

.. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.

On Mon, Jan 13, 2025 at 8:21 PM N. Albert via plug <plug@lists.phillylinux.org> wrote:

I've had some problems with Debian 12 for a while, and I'd be interested
to know if anyone else has experienced a similar issue.

A while back, I was hooking a POS (point of sale, it works fine) printer
for printing alarm logs, and I intended to connect it to a Debian server
to send jobs to it, since Linux is more conducive to automation. I
couldn't use it locally, since it was connected to my one tower server
without a parallel port. Hardware was your typical friendly OptiPlex
mini tower. It didn't work, and going through dmesg at the time and
putzing with various pp drivers and the like, I was seeing some
parport-related stuff but not everything you'd expect to see on a
working system, and I couldn't get it working successfully.

Note that I was not using CUPS (which for this, I would consider to be
unwanted/unneeded printer bloat), so there were theoretically fewer
things that could go wrong. My plan was to write directly to the
parallel port device, and even that did not work. From my notes, here
are some of the oddities I uncovered:

# lspci -v | grep "arallel"
# (No output... there should be though)

# dmesg | grep "parport"
[ 17.617561] parport_pc 00:03: reported by Plug and Play ACPI
[ 17.617644] parport0: PC-style at 0x378 (0x778), irq 7
[PCSPP,TRISTATE,EPP]
[ 617.160115] lp0: using parport0 (interrupt-driven).
# (Some output from dmesg... but there should be more)

# echo "test" > /dev/lp0 # Succeeds, but does nothing
# echo "test" > /dev/parport0
-bash: echo: write error: Invalid argument

I later had another driver-related issue with Debian 12 not installing
successfully in HyperV on Server 2008 R2, but the Debian 11 installer
worked (the issue appears to be purely with the installer). After this,
I suspected driver regressions in Debian 12 that may have broken the
parallel port. I reported that driver issue[1] to the Debian team, but
not my parallel port issues since at the time I didn't feel I had enough
evidence.

The hardware (OptiPlex 745 MT) should work just fine. At the time, I
moved the connection to a Windows server on similar hardware (OptiPlex
980 MT), and unsurprisingly, it works perfectly fine in Windows.
Unfortunately, I wanted to send jobs to it from a Linux machine, and
Windows doesn't natively have the ability to run a simple TCP print
server on port 9100. I couldn't even find any working software for
Windows that would allow me to simply send jobs to a TCP port and have
them print, and I don't have much of a Windows development background
either so I gave up on that approach. I ended up having to set up a
service user to spool jobs to LPT locally and use smbclient to submit
print jobs from the original Linux server that needed to print jobs, to
the Windows server. Clunky, but this actually worked fine:

echo "Hello world 123" | smbclient //$SERVER/$PRINTER -U
$DOMAIN/$USERNAME%$PASSWORD -c "print -" # worked

Fast forward to recently, I ended up finally disabling NTLM completely
in Active Directory, and with a few exceptions, everything is working
fine... except now I can't print to the Windows Server anymore since the
Linux server isn't domain joined (and I don't want to join it) so it
can't use Kerberos. It's not working even with exceptions for both hosts
involved, so I think this is my cue that my original workaround was
silly from the beginning and I should try to get it working the way I
wanted to originally, using the parallel port... under Linux. It would
be a lot simpler, and I wouldn't have to deal with Active Directory either.

It's a bit difficult for me to test, since every other machine I have
with a parallel port is running either Windows or Windows Server, and
this server is also doing other things. Before I try downgrading the
server to Debian 11 to see if that helps, I wanted to see if anyone had
any datapoints that either support or contradict my experiences thus
far. Is *anyone* using the parallel port under Debian 12 (or another
version), on any hardware, with success?

[1]
https://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg2006966.html
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug