Print photos to DNP DS-RX1HS on Linux

I have a DNP DS-RX1HS photo printer for the occasional photobooth “gig” and every so often, I would like to print out some photos. When I do print photos, I would have get the image to a laptop and if I picked up the T430, I would have to reboot that into Windows otherwise there’s the MacBook Pro that is sometimes out of battery because it is an old laptop. I would like to get out of that business and print to the printer from whatever device I am working on.

Unfortunately DNP’s website offers drivers for Windows or macOS but not Linux. Since macOS uses CUPS I thought I could add the printer on Linux using its PPD. After looking at the PPD, it became apparent that this was not going to work. The PPD had calls to binaries such as rastertodnp and without the source I would not be able to recompile the binaries to work on Linux.

For kicks and giggles, I searched GitHub for “dnp ds rx1” to see if anyone has attempted something similar. I came across a few results that mentioned Gutenprint. Promising.

Looking at the ArchWiki for a page about Gutenprint, I installed the gutenprint and foomatic-db-gutenprint-ppds packages. Then I added the printer via the CUPS web interface since the system-config-printer utility kept throwing a client-error-not-possible error. I could add the printer using Gnome’s Printers settings panel, but I prefer to name the printers (ds-rx1hs).

Once the printer was added, I was able to print photos to the DS-RX1HS from Linux. There is also support for cutting the photos at the 2 inch/horizontally halfway point for photo strips which is NEAT. At this point, I am considering getting a RaspberryPI and set it up as a print server such that I am able to print photos to it from my desktop and/or my laptop.

Yet another post about setting up alerts

tl;dr Set up e-mail alerts so that you are alerted to when things (start to) go wrong.

This morning, I got an email from my FreeNAS server with the following:

New alerts:
* Boot Pool Status Is ONLINE: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected.

Logging in to the server, I ran zpool status freenas-boot to see the state of the pool:

# zpool status
  pool: freenas-boot
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 98.5K in 0 days 01:08:27 with 0 errors on Wed May 27 04:53:27 2020
config:

	NAME                                            STATE     READ WRITE CKSUM
	freenas-boot                                    ONLINE       0     0     0
	  mirror-0                                      ONLINE       0     0     0
	    gptid/44bef123-fee5-11e4-9e92-0cc47a4a5aff  ONLINE       0     0     1
	    ada0p2                                      ONLINE       0     0     0  block size: 512B configured, 4096B native

errors: No known data errors

Luckily, this pool is made up of a mirrored vdev: a USB flash drive (gptid/44bef123-fee5-11e4-9e92-0cc47a4a5aff) and an SSD (ada0/p2). Per zpool status, I ran zpool clear to clear the error. The next scrub will be towards the end of the month (June), so we will see if this error comes back. In the meantime, I have started to look into replacing the flash drive with a SATA DOM.

# zpool clear freenas-boot

# zpool status freenas-boot
  pool: freenas-boot
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
	Expect reduced performance.
action: Replace affected devices with devices that support the
	configured block size, or migrate data to a properly configured
	pool.
  scan: scrub repaired 98.5K in 0 days 01:08:27 with 0 errors on Wed May 27 04:53:27 2020
config:

	NAME                                            STATE     READ WRITE CKSUM
	freenas-boot                                    ONLINE       0     0     0
	  mirror-0                                      ONLINE       0     0     0
	    gptid/44bef123-fee5-11e4-9e92-0cc47a4a5aff  ONLINE       0     0     0
	    ada0p2                                      ONLINE       0     0     0  block size: 512B configured, 4096B native

errors: No known data errors

The moral of this story: set up email alerts or some kind of alerting system to alert you when things (start to) go wrong.

blog.

This [blog] has been an idea on the back burner for a very long time. Reasons for this include:

  • What will I use? (WordPress, GitHub Pages, etc.)
  • What will the domain name be?

As you can tell, I have decided to use WordPress and this subdomain. Maybe one day I will get creative and flip everything around but this is the lane that I have chosen to drive in (for now).

INSTALL_VERIFICATION_FAILED_ALERT_INFO Error with Office 365 and macOS

While installing Office 365 (16.25.19051201) for a client (macOS High Sierra 10.13.6), Microsoft AutoUpdate (MAU) pops up with an error saying “INSTALL_VERIFICATION_FAILED_ALERT_INFO”. Clicking OK would open the browser and it would proceed to download the latest AutoUpdate to install. However, at the end of the install the error comes up again. Repeat until annoyed.

While going through many Q & A pages, I recall running into a folder that I couldn’t access without elevated privileges. I don’t know macOS internals that well so I didn’t have the slightest idea as to the purpose of that folder.

It turns out that the permissions on /Library/PrivilegedHelperTools were borked. Unfortunately, I didn’t capture what the state was but it was probably something along the lines of rwx------.

Comparing with two devices I had access to, the permissions were the following:

# ls -ld /Library/PrivilegedHelperTools
drwxr-xr-t  13 root  wheel  416 Feb 22 18:32 /Library/PrivilegedHelperTools

As root, I semi-sorted the permissions with # chmod 755 /Library/PrivilegedHelperTools and rebooted. Upon reboot, the permissions were rwxr-xr-t and MAU and friends appeared to be happy.