dd works fine, you'd use it something like this

dd if=/dev/zero of=/dev/[the drive] status=progress conv=fsync bs=4M

if: input file

of: output file

status=progress: shows progress

conv=fsync: basically does the equivalent of running "sync" after the command, makes sure all the kernel buffers have actually written out and are on the device. This causes the command to "hang" near the end depending on how much RAM is installed on the computer. It's not actually hanging it's just finishing writing out the data that's still cached in RAM. This can take a while depending on drive speed and quantity of system RAM.

bs=4M sets the block size to something high enough you're not CPU bottlenecked. Not particularly important exactly what the value is, 4M is a good sane default for most things including this full disk operation.

edit: one pass of zeros is enough to protect against all trivial data recovery techniques. If your threat model includes three letter agencies the hammer and drill bit technique is 👍

Make sure CUPS is running, go to http://localhost:631 to see the administration interface for CUPS. You'll probably wanna checkout the ArchWiki page about CUPS too, it's relevant to many distributions. If it's a USB printer and not IPP you'll need to make sure the right drivers are being used. IPP printers work outta the box.