returned 1: lpadmin: Success about puppet-cups HOT 8 CLOSED

Some observations here:

• ipptool -c [...] exits 1, but claims successful-ok, but on STDERR. We have seen such strange behavior in #19 where it was caused by a patch to CUPS by the Debian team.
• Because of #19 a fallback mechanism using ipptool -t [...] was added to the module (2.0.0 and above). This fallback, however, was skipped in your execution.
• The returned 1: lpadmin: Success points to a new and unexpected behavior of CUPS - or maybe the dash in PK519-4 was not escaped properly when shelling out.

I'll try to confirm it in a Vagrant box.

from puppet-cups.

I missed the detail that types::files is supplied by ghoneycutt-types from the forge. It allows me to make files, packages, etc without having many stanzas in site.pp of the form:

$packages = lookup('packages')
$packages.each | $key, $value | {
  package {$key:
    * => $value
  }
}

from puppet-cups.

I attach my PPD, you will need to take .txt off the end of the file name.
KOC658UX.ppd.txt

from puppet-cups.

I have narrowed the problem down to the fact that all commands are issued correctly, but on the system you describe, all commands using encrypted communication (i.e. the -E in lpadmin -E) will exit 1 despite achieving success.

I have checked this behavior with PPD files from several vendors and - as to be expected, see #6 (comment) - this problem only seems to arise with PPD files from KonicaMinolta.

Your CUPS installation now seems to mind these aberrations more than before - at least when using encrypted communication. I have also run your configuration against Fedora 28 with CUPS 2.2.6 where the problems do not arise, so it was either introduced by CUPS 2.2.7 or a patch by the Debian / Ubuntu community.

While dropping the usage of the '-E' flag in lib/puppet/provider/cups_queue/cups.rb would solve your issue for now, it is merely a cure of the symptom, not of the underlying issue, so we're reluctant to do that. Also, lowering your security standards to overcome someone else's bug never seems to be a good idea. Nevertheless it would be a hot fix you could apply locally to your setup to get it running until there's a better option.

Let's keep this issue open to see how many users are actually affected. If the issue becomes big enough, we'll have to add more error handling to the module.

from puppet-cups.

I will try editing my PPD file. Thank you for the heads-up.

from puppet-cups.

I've updated to a more recent PPD and also stripped lines out of it based on #19. The queues are now forming consistently, thank you for the advice. I am now able to support printing at my site.

I still get

root@17dcompd454:/usr/share/cups/model# ipptool -t ipp://localhost/printers/USB_Building_Printing /usr/share/cups/ipptool/get-printer-attributes.test
"/usr/share/cups/ipptool/get-printer-attributes.test":
    Get printer attributes using Get-Printer-Attributes                  [FAIL]
        RECEIVED: 10361 bytes in response
        status-code = successful-ok (successful-ok)
        Duplicate "pwg-raster-document-type-supported" attribute in printer-attributes-tag group
        Duplicate "pwg-raster-document-resolution-supported" attribute in printer-attributes-tag group

(an Ubuntu/Debian bug?) and

Debug: IPP query 'ipptool -c ipp://localhost/printers/USB_Building_Printing /dev/stdin' failed.
EXITCODE: 1
STDIN:
            {
              OPERATION Get-Printer-Attributes
              GROUP operation
              ATTR charset attributes-charset utf-8
              ATTR language attributes-natural-language en
              ATTR uri printer-uri $uri
              STATUS successful-ok
              DISPLAY printer-make-and-model
            }

STDOUT:

STDERR:
successful-ok

when I run puppet agent -td.

I attach my new and amended PPD for testing and also in the hope that it will be useful for anyone else using Konica Minolta C759, C659, C658, C558, C458, C368, C308, C258, C287, C227, C3851, C3851FS, or C3351 and tearing their hair out.

from puppet-cups.

The duplicates in the IPP response stem from this Debian patch:
https://sources.debian.org/patches/cups/2.1.3-5/pwg-raster-attributes.patch/

The debug message comes from calling Puppet.debug in the rescue branch of

from puppet-cups.

Maybe this should be replaced with a less noisy message.

It's apparent from the earlier issue with Konica PPDs that this will affect anyone with certain Konica models, and it seems unlikely that Konica are going to publish PPDs that pass cupstestppd in the foreseeable future.

Suggestion: If your module is able to detect that a PPD is from Konica (I'm guessing "yes" because the PPD says *Manufacturer: "KONICA MINOLTA" on line 8), maybe the error can say something about Konica PPDs being not compliant with RFC 2911 and directing them to #6 or a similar piece of documentation? It seems likely that queries like this will arise again because of Konica's dominance in the "pull printing" (ie authenticated job release) market: if the error message tells people what to do, you get fewer issues.

from puppet-cups.