Could not prefetch cups_queue provider 'cups' on Ubuntu 18.04 about puppet-cups HOT 14 CLOSED

Have you tried this? https://github.com/leoarnold/puppet-cups#systemd-based-linux-distributions

from puppet-cups.

Regenerating types on the puppet master seems to make the Pis happy, but the Ubuntu systems are still giving the same error. ETA: nope, the Pis are happy the first run after removing the queue by hand and then make the error message forever after.

Uncommenting the PPD line about the filter and installing the filter Perl script makes no difference. I tend not to use the filter because it's for managing user boxes that we don't make use of because we have PCounter.

from puppet-cups.

Thanks for the suggestion. It fails pdk test unit though. Where does the variable $::systemd in the workaround class come from?

from puppet-cups.

Ah, I see, it's a custom fact. Unit tests now happy.

from puppet-cups.

Manifest now saying:

class profiles::printing {

  # for convenience so I don't type the same thing over and over
  $ppdpath    = '/usr/share/cups/model'
  $filterpath = '/usr/lib/cups/filter'
  $filter     = 'KMbeuEmpPS.pl'
  $models     = ['KMC759ux.ppd']
  case $facts['lsbdistid'] {
    'Raspbian': {
      $packages = ['cups-bsd', 'a2ps']
    }
    default: {
      $packages = ['cups-bsd', 'a2ps', 'indicator-printers']
    }
  }


  include ksmb

  class { 'cups':
    default_queue => 'USB_Building_Printing',
    papersize     => 'A4',
  }

  include cups::workarounds::systemd_service_restart

  package { $packages:
    ensure => installed,
  }

  file { $ppdpath: ensure => directory }

  file { $filter:
    ensure  => file,
    replace => yes,
    mode    => '0755',
    path    => "${filterpath}/${filter}",
    source  => "puppet:///modules/profiles/ppds/${filter}"
  }

  $models.each | $model | {
    file { $model:
      ensure  => file,
      replace => yes,
      source  => "puppet:///modules/profiles/ppds/${model}",
      path    => "${ppdpath}/${model}",
      group   => 'lp',
      mode    => '0644',
    }
  }

  cups_queue { 'USB_Building_Printing':
    ensure      => 'printer',
    uri         => 'ksmb://cs-print/USB-BUILDING-PRINTING',
    ppd         => "${ppdpath}/KOC759UX.ppd",
    shared      => false,
    enabled     => true,
    accepting   => true,
    description => 'All Urban Sciences printers, swipe your campus card at any printer to collect your job.',
    options     => {
      'KMDuplex'      => '2Sided',
      'PageSize'      => 'A4',
      'InputSlot'     => 'Tray4',
      'PaperSources'  => 'PC215',
      'Finisher'      => 'FS533',
      'KOPunch'       => 'PK519-4',
      'SaddleUnit'    => 'None',
      'PrinterHDD'    => 'HDD',
      'SelectColor'   => 'Grayscale',
      'Model'         => 'C458',
      'TextPureBlack' => 'On',
    },
  }

}

Acceptance test results:

• The Pis are happy.
• But the Ubuntu 18.04s are still saying:

Debug: Prefetching cups resources for cups_queue
Error: Could not prefetch cups_queue provider 'cups': IPP query 'ipptool -c ipp://localhost/ /dev/stdin' failed.
EXITCODE: 1
STDIN:
          {
            OPERATION CUPS-Get-Classes
            GROUP operation
            ATTR charset attributes-charset utf-8
            ATTR language attributes-natural-language en
            DISPLAY printer-name
            DISPLAY member-names
          }

STDOUT:

STDERR:
ipptool: Unable to connect to localhost on port 631 - Operation now in progress

Debug: Storing state
Debug: Pruned old state cache entries in 0.00 seconds
Debug: Stored state in 0.04 seconds
Error: Failed to apply catalog: IPP query 'ipptool -c ipp://localhost/ /dev/stdin' failed.
EXITCODE: 1
STDIN:
          {
            OPERATION CUPS-Get-Classes
            GROUP operation
            ATTR charset attributes-charset utf-8
            ATTR language attributes-natural-language en
            DISPLAY printer-name
            DISPLAY member-names
          }

STDOUT:

STDERR:
ipptool: Unable to connect to localhost on port 631 - Operation now in progress

The Error: Could not prefetch cups_queue provider 'cups' grabs my eye.

from puppet-cups.

At prefetch, Puppet takes a look around to find which print queues are installed

It does so by running a few executions of the ipptool command line utility

The problem is Unable to connect to localhost on port 631 - Operation now in progress, i.e. the CUPS service is currently not listening on port 631, probably because it is restarting in order to implement the changed configuration file.

The workaround drops in a config which tells systemd that the CUPS service is not ready until it is listening to that specific port

Obviously, systemd is failing us here.

from puppet-cups.

I am firing up git's magic time machine because this talk of systemd is ringing a bell.

from puppet-cups.

Summary: running cupsd with -f doesn't help.

Some years ago, a previous author of Puppet code at our site added a "monkey patch" to systemd:
/etc/systemd/system/cups.service

[Unit]
Description=CUPS Printing Service
Documentation=man:cupsd(8) man:cupsd.conf(5)
Requires=cups.socket
[Service]
ExecStart=/usr/sbin/cupsd -f
[Install]
Also=cups.socket cups.path
WantedBy=printer.target

I can't figure why this is needed and note that the cupsd manual says to use -l in the systemd unit, so I removed the monkey patch. When this problem started, I suspected the monkey patch to be a fix for it. Reinstating it doesn't resolve this problem though.

from puppet-cups.

My earlier manifests that don't use roles and profiles but used cups::resources in hiera were not affected. I'm going to try using cups::resources in Hiera within roles and profiles, somehow, but that will be tomorrow.

from puppet-cups.

I'm not sure why, but forcibly removing the monkey patch with file { '/etc/systemd/system/cups.service': ensure => absent } allows me to use cups_queue in my manifest, whereas not forcibly removing an already-present monkey patch (e.g. as a result of moving nodes from production to test without reinstalling the OS) forces me to use cups::resources hashes in Hiera. Even though cups::resources are turned into cups_queues.

Not complaining, my manifests now work.

from puppet-cups.

Sorry for taking up your time with something that turned out to be my problem.

from puppet-cups.

Here's some food for thought, in case you want to dig deep: A plain

file { '/etc/systemd/system/cups.service':
# ....
}

is bound for trouble. You need something to trigger a systemctl daemon-reload to make systemd aware of the (changed) service file. Then again, I'm unsure about how Ubuntu 18.04 LTS runs CUPS. Maybe there's even a conflict of interest with an old /etc/init.d/cups script.

Furthermore the monkey-patch should be integrated into the Puppet dependency tree, c.f.
https://github.com/leoarnold/puppet-cups#automatic-dependencies
and

from puppet-cups.

You need something to trigger a systemctl daemon-reload to make systemd aware of the (changed) service file.

file { '/etc/.../cups.service': params => list } ~> class { 'cups': params => list } was in the old manifests to do exactly that, and is in the current manifest with ensure => absent to make the cups class reapply after removing the file, which causes at least one service reload based on the reports Foreman shows me.

Then again, I'm unsure about how Ubuntu 18.04 LTS runs CUPS. Maybe there's even a conflict of interest with an old /etc/init.d/cups script.

I will take a look on Monday (I use 18.04 at work) and report back. It's the least I can do.

from puppet-cups.

There is still cups and cups-browsed in /etc/init.d. The stock service files don't reference them. I removed the symlinks from /etc/rc5.d and rebooted and I still have CUPS running.

I suspect that the init.d files are packaged in CUPS for Systemd refuseniks and aren't relied on at all on Systemd systems.

from puppet-cups.