default queue support

[jflorian]

In your README.md you state this module has the limitation that it "currently does not set default printers." Then later in the OSX-specifics section you mention "If you want to set the default printer, you cannot use lpoptions or lpadmin to do it." While I don't have an OSX and won't contest anything you've said there, I do see that the lp(1) man page has:

CUPS provides many ways to set the default destination. The "LPDEST" and "PRINTER"
environment variables are consulted first. If neither are set, the current default set using the
lpoptions(1) command is used, followed by the default set using the lpadmin(8) command.

Likewise, lpoptions(1) states:

-d destination[/instance]
Sets the user default printer to destination. If instance is supplied then that particular
instance is used. This option overrides the system default printer for the current user.

Indeed the "loptions -d foo" approach works for me in Fedora. It seems to me that this should be relatively easy to implement. Or am I missing something here?

[mosen]

Hey there,
Yep, my README is a bit contradictory there. Initially I had an option to set the default printer, but it did not work on OS X, due to the default printer being determined in a different way (I.E not through the -d option).

I'm pretty happy to reinstate the option, but it won't do anything on OSX so I'll at least need a footnote for that.

[jflorian]

I would much appreciate the option. I am baffled though about the inconsistent behavior under OS X, given that Apple is the CUPS maintainer these days.

On January 4, 2015 1:48:05 AM EST, mosen [email protected] wrote:

Hey there,
Yep, my README is a bit contradictory there. Initially I had an option
to set the default printer, but it did not work on OS X, due to the
default printer being determined in a different way (I.E not through
the -d option).

I'm pretty happy to reinstate the option, but it won't do anything on
OSX so I'll at least need a footnote for that.

---

Reply to this email directly or view it on GitHub:
#41 (comment)

Composed with a magnetized needle and a steady hand. Please excuse my brevity.

[mosen]

Hi @jflorian, latest HEAD of puppet-cups includes support for setting the default destination through the use of a new resource type called default_printer. It's an ensurable resource so you can declare it like:
default_printer { 'Queue_Name':
ensure => present,
require => Printer['Queue_Name'],
}

The reason for not adding printer { 'x': default => true }, was that I could not find a way (other than selectively editing the /etc/cups/lpoptions file) to un-default a destination, therefore default => false would have been impossible at the moment. I'm also of the opinion that "defaults" should be managed separately to the destinations/queues themselves. Feel free to disagree!

[jflorian]

@mosen I'm glad to see this happen. I think a new default_printer resource actually makes more sense for a number of reasons, especially considering there can only be one default printer anyway.

I'd like to give it a test, but presently I'm using a "puppet module install mosen-cups". Is there a good way to update that from HEAD? I have a local git clone at HEAD elsewhere and I guess I could just rsync, but was wondering if there was a better way to handle this.

[mosen]

hi @jflorian, looking at the puppet module install switches, it doesnt look like theres a reasonable way to install from github head. I took a look at publishing a beta release on the forge and that doesn't seem possible without forcing an upgrade for everyone else.
For the moment you might have to clone a copy of HEAD to test with, and if i can close all remaining issues I will probably make this the next release, as it solves a lot of issues with the previous one.

[jflorian]

On 03/03/2015 03:49 AM, mosen wrote:

hi @jflorian https://github.com/jflorian, looking at the puppet
module install switches, it doesnt look like theres a reasonable way
to install from github head. I took a look at publishing a beta
release on the forge and that doesn't seem possible without forcing an
upgrade for everyone else.
For the moment you might have to clone a copy of HEAD to test with,
and if i can close all remaining issues I will probably make this the
next release, as it solves a lot of issues with the previous one.

—
Reply to this email directly or view it on GitHub
#41 (comment).

Okay, will do. Sorry for the late response, I had a mail rule horribly
misconfigured.

[mosen]

Hi @jflorian I have uploaded release 1.4.0 to the forge. Let's see if this default_printer resource resolves the issue.

[jflorian]

Thanks @mosen! It worked for me. I gave it two tests. First, I just added the new default_printer resource and applied to a host where the print queues were already created. This did everything I would expect:

Notice: /Stage[main]/Doubledog::Subsys::Cups/Default_printer[brother-br3]/ensure: created

For the second test, I did an lpadmin -x QUEUE for each queue (on the same host) to validate creating the print queues and setting the default in one go. Here things were a bit strange:

Notice: /Stage[main]/Doubledog::Subsys::Cups/Printer[brother-guten]/ensure: created
Notice: /Stage[main]/Doubledog::Subsys::Cups/Printer[brother-br3]/ensure: created

Both queues were created as expected and the default was set again as expected, but oddly there was no message from Puppet for the default_printer resource this time. I got my default, so I'm happy but thought I'd share this oddity in case there's a grue lurking within.

[mosen]

Hi @jflorian I would expect that behavior. The default printer remains even after the queue is deleted I.E its possible for cups to have a default queue that isn't valid at all.

[jflorian]

On 03/25/2015 05:22 PM, mosen wrote:

Hi @jflorian https://github.com/jflorian I would expect that
behavior. The default printer remains even after the queue is deleted
I.E its possible for cups to have a default queue that isn't valid at all.

—
Reply to this email directly or view it on GitHub
#41 (comment).

Oh, that would explain some of the funny noises coming out of lpstat
after I removed the queues but before I ran Puppet the 2nd time. In
that case, I think we're all good.

Thanks so much for implementing this!