Document how to print things in Qubes OS

[ninavizz]

How to file a helpful issue

The problem you're addressing (if any)

Recently this PR was filed, to disable CUPS by default in Qubes OS. Which was good, because the core security vulnerability did and does need addressing.

For native Linux users, they may see they cannot print and intuit "Oh, I should see if CUPS is enabled."

For non-Linux native users, networking, printing, and files management, are all handled by native apps (not with unique names, just "Print" and "Network" functionalities non-developers don't see as stand-alone apps). The concept that "Hey, I should get a different printer utility" never occurs to non-native Linux users, because those things "are just a part of" the walled-garden ecosystems of Windows and Mac OS.

The solution you'd like

Create a Qubes Docs How To item that documents how to print files. I'd recommend "How to use a printer with Qubes." Primary points to address should be:

1. Qubes treats all external devices special. Here's how (link to devices how-to). 2. Welcome to Linux. All OS functionality within Qubes OS, is done by the qube a user is within—and most of those, are Linux qubes. For Windows or Mac qubes, skip ahead to step 6. 3. In Linux, CUPS is the name of the print utility. While Mac and PC OS' come with basic utilities such as those for network management, files management, disk maintenance, and printing, all bundled in—in Linux environments they often exist as apps identified as 3rd party apps. For printing, CUPS is that utility. 4. However, CUPS was disabled by Qubes OS as its installation default, because it presents vulnerabilities. Provide some link to learn more about what those might be, or more simply explain "this is generally a good practice, to keep 'off' what you don't usually need." 5. How to re-enable CUPS; be that enablement on the command line or in the GUI, and at the Template or app-qube level. 6. Now, do like you usually do, with steps 1-5 working. Then, once they have a printer attached to an example qube and are ready to print from a common example app, how they would do that. While this may seem obvious, it will let the user know that this is the final end-point in their inquiry.

How is this helpful to users?

Lots of us just need our treeware. ~3500 of the 17k respondents to Qubes' general survey, said they regularly use a printer "with a laptop." ~18% are students, ~12% academics, ~8% activists; yes, ~30% identify as technologists, but a not-insignificant amount likely still need to print.

[DemiMarie]

Some notes so far:

• Prior to https://github.com/QubesOS/qubes-core-agent-linux/pull/364, CUPS was enabled in all template-based qubes that do not provide networking. That was both a security and a performance problem. CUPS is still the correct way to print from a Linux qube, but it should only be enabled in the specific app qube that needs it.
• Turning on CUPS in a template will turn it on for all qubes based on that template, which is almost never what one wants. Usually, one wants to print from a single qube: either the qube which the external device is attached to, or sys-net for a network printer.

[andrewdavidwong]

The solution you'd like

Create a Qubes Docs How To item that documents how to print files. I'd recommend "How to use a printer with Qubes." Primary points to address should be:

1. Qubes treats all external devices special. Here's how (link to devices how-to). 2. Welcome to Linux. All OS functionality within Qubes OS, is done by the qube a user is within—and most of those, are Linux qubes. For Windows or Mac qubes, skip ahead to step 6. 3. In Linux, CUPS is the name of the print utility. While Mac and PC OS' come with basic utilities such as those for network management, files management, disk maintenance, and printing, all bundled in—in Linux environments they often exist as apps identified as 3rd party apps. For printing, CUPS is that utility. 4. However, CUPS was disabled by Qubes OS as its installation default, because it presents vulnerabilities. Provide some link to learn more about what those might be, or more simply explain "this is generally a good practice, to keep 'off' what you don't usually need." 5. How to re-enable CUPS; be that enablement on the command line or in the GUI, and at the Template or app-qube level. 6. Now, do like you usually do, with steps 1-5 working. Then, once they have a printer attached to an example qube and are ready to print from a common example app, how they would do that. While this may seem obvious, it will let the user know that this is the final end-point in their inquiry.

IMHO, users shouldn't have to read all of this just to be able to print something. Most users won't even think to look for such a doc page when their printer doesn't work, and they won't want to read it. Even if they try to read it, many won't understand it all and will still struggle to get printing working.

IMHO, this should be a feature request for an easy-to-use print widget/tool rather than a documentation issue. Put the smarts into the software rather than trying to stuff them into each user's head.

If a software solution simply isn't going to happen, then I support the creation of this documentation, but I'm not qualified to write it, as I know very little about CUPS. As usual, I think a lot of the proposed non-Qubes-specific content (like "welcome to Linux" and "what is CUPS?") should instead be links to external content, but I won't rehash that debate here.

(@DemiMarie, what does P: blocker mean for a documentation issue? "Blocker" means it's preventing a release (or would have if known at the time), but documentation issues generally aren't on a release milestone.)

[ninavizz]

@andrewdavidwong I cannot disagree with your preference for a tool, and I agree its quite an un-favorable resolution to simply document a workaround. That said, it feels like the best we can do with the resources the project has r/n... and, Marek merged the PR, so presumably this will be impacting users, soon.

@deeplow @svensemmler may either of you be able to potentially help? Yes, I hope to procure my own Qubes machine, no later than April.

[DemiMarie]

(@DemiMarie, what does P: blocker mean for a documentation issue? "Blocker" means it's preventing a release (or would have if known at the time), but documentation issues generally aren't on a release milestone.)

Prior to https://github.com/QubesOS/qubes-core-agent-linux/pull/364 printing at least had a chance of working in a default configuration, once the printer was attached to the right qube. Now it has zero chance, since the service responsible for it (CUPS) isn’t even running. So from that perspective, this is a regression. I do not intend to revert the PR, but a better solution is certainly needed.

More concretely: Having CUPS running by default in one AppVM is fine. Having CUPS running by default in all AppVMs is not.

IMHO, users shouldn't have to read all of this just to be able to print something. Most users won't even think to look for such a doc page when their printer doesn't work, and they won't want to read it. Even if they try to read it, many won't understand it all and will still struggle to get printing working.

IMHO, this should be a feature request for an easy-to-use print widget/tool rather than a documentation issue. Put the smarts into the software rather than trying to stuff them into each user's head.

YES PLEASE!!! It took me quite a while to get printing working reliably. There is no way a non-technical person could be expected to do that. Is a sys-print qube an option? Perhaps with a “Print via Qubes OS“ GUI option? That would create a PDF, which would be sanitized in a DispVM (via qvm-convert-pdf) before being opened in sys-print. The user could then use the standard print dialog.

[andrewdavidwong]

(@DemiMarie, what does P: blocker mean for a documentation issue? "Blocker" means it's preventing a release (or would have if known at the time), but documentation issues generally aren't on a release milestone.)

Prior to QubesOS/qubes-core-agent-linux#364 printing at least had a chance of working in a default configuration, once the printer was attached to the right qube. Now it has zero chance, since the service responsible for it (CUPS) isn’t even running. So from that perspective, this is a regression. I do not intend to revert the PR, but a better solution is certainly needed.

More concretely: Having CUPS running by default in one AppVM is fine. Having CUPS running by default in all AppVMs is not.

Ok, but my question was more about issue tracking, specifically whether P: blocker is meaningful on an issue that isn't on any release milestone. I think the other priority values (i.e., P: critical and below) are still meaningful on such issues. I just wanted to make sure there wasn't a specific, strong reason for choosing P: blocker over P: critical that I wasn't seeing.

Two questions about the CUPS change:

1. When this update lands in stable, will it turn off CUPS in all existing qubes, or will it only affect new qubes?
2. Will this also disable "print to PDF" functionality, or only actual printers?

IMHO, users shouldn't have to read all of this just to be able to print something. Most users won't even think to look for such a doc page when their printer doesn't work, and they won't want to read it. Even if they try to read it, many won't understand it all and will still struggle to get printing working. IMHO, this should be a feature request for an easy-to-use print widget/tool rather than a documentation issue. Put the smarts into the software rather than trying to stuff them into each user's head.

YES PLEASE!!! It took me quite a while to get printing working reliably. There is no way a non-technical person could be expected to do that.

Yes, if even you struggled with it, there is no hope for the rest of us. :laughing:

Is a sys-print qube an option? Perhaps with a “Print via Qubes OS“ GUI option? That would create a PDF, which would be sanitized in a DispVM (via qvm-convert-pdf) before being opened in sys-print. The user could then use the standard print dialog.

Something like this sounds much better than having every user try to implement their own DIY solution by following a doc. (We have to remember that many users misinterpret the documentation they read and struggle to follow steps exactly as written, so even with perfect documentation, user mileage will vary widely.)

[marmarek]

When this update lands in stable, will it turn off CUPS in all existing qubes, or will it only affect new qubes?

All that haven't cups enabled explicitly before.

You can re-enable in VM settings - go to "services" tab, select "cups" from the drop-down and click "add".

Will this also disable "print to PDF" functionality, or only actual printers?

It depends on application, but in most (all?) cases it will be unaffected.

[DemiMarie]

(@DemiMarie, what does P: blocker mean for a documentation issue? "Blocker" means it's preventing a release (or would have if known at the time), but documentation issues generally aren't on a release milestone.)

Prior to QubesOS/qubes-core-agent-linux#364 printing at least had a chance of working in a default configuration, once the printer was attached to the right qube. Now it has zero chance, since the service responsible for it (CUPS) isn’t even running. So from that perspective, this is a regression. I do not intend to revert the PR, but a better solution is certainly needed. More concretely: Having CUPS running by default in one AppVM is fine. Having CUPS running by default in all AppVMs is not.

Ok, but my question was more about issue tracking, specifically whether P: blocker is meaningful on an issue that isn't on any release milestone. I think the other priority values (i.e., P: critical and below) are still meaningful on such issues. I just wanted to make sure there wasn't a specific, strong reason for choosing P: blocker over P: critical that I wasn't seeing.

Two questions about the CUPS change:

1. When this update lands in stable, will it turn off CUPS in all existing qubes, or will it only affect new qubes?

Existing qubes will not start CUPS unless CUPS has been explicitly enabled.

2. Will this also disable "print to PDF" functionality, or only actual printers?

“print to PDF” should work fine. Linux is not Windows, and “print to PDF” on Linux does not rely on CUPS (or any other service, for that matter).

IMHO, users shouldn't have to read all of this just to be able to print something. Most users won't even think to look for such a doc page when their printer doesn't work, and they won't want to read it. Even if they try to read it, many won't understand it all and will still struggle to get printing working. IMHO, this should be a feature request for an easy-to-use print widget/tool rather than a documentation issue. Put the smarts into the software rather than trying to stuff them into each user's head.

YES PLEASE!!! It took me quite a while to get printing working reliably. There is no way a non-technical person could be expected to do that.

Yes, if even you struggled with it, there is no hope for the rest of us. :laughing:

I mean I am no expert on CUPS, so there is a chance someone else could have done better. But a non-technical user would have no chance.

Is a sys-print qube an option? Perhaps with a “Print via Qubes OS“ GUI option? That would create a PDF, which would be sanitized in a DispVM (via qvm-convert-pdf) before being opened in sys-print. The user could then use the standard print dialog.

Something like this sounds much better than having every user try to implement their own DIY solution by following a doc. (We have to remember that many users misinterpret the documentation they read and struggle to follow steps exactly as written, so even with perfect documentation, user mileage will vary widely.)

This was the solution I wound up implementing, but it was sufficiently complex (involving a named disposable qube and a custom qrexec service) that most users could not be implemented to do so.

[ninavizz]

I mean I am no expert on CUPS, so there is a chance someone else could have done better. But a non-technical user would have no chance.

Demi, friend—I +1 Andrew's astute 😆 assessment. If you can't figure something out, few other humans could.

A potentially dumb question for @DemiMarie — per your PR/remediation, will CUPS even still exist in the services menu Marek described, above? If "yes," then this sounds like a very simple 2-sentence "How To" blab in the docs.

Just triple-checking, because... well, yes, I do that.

[DemiMarie]

I mean I am no expert on CUPS, so there is a chance someone else could have done better. But a non-technical user would have no chance.

Demi, friend—I +1 Andrew's astute laughing assessment. If you can't figure something out, few other humans could.

@michaelrsweet probably could figure out the CUPS side of the situation, but that is because he is the author :laughing:. The problems I ran into seemed to be race conditions of some sort, if I recall correctly.

A potentially dumb question for @DemiMarie — per your PR/remediation, will CUPS even still exist in the services menu Marek described, above? If "yes," then this sounds like a very simple 2-sentence "How To" blab in the docs.

It isn’t present as an entry that can be checked, but it is easy to add. That said, the lack of discoverability is a serious problem.

Just triple-checking, because... well, yes, I do that.

And I am glad that you do.

[marmarek]

It isn’t present as an entry that can be checked, but it is easy to add. That said, the lack of discoverability is a serious problem.

https://github.com/QubesOS/qubes-core-agent-linux/commit/5c8fab9eab528c88447b6539567e094de2f811ef

[ninavizz]

A potentially dumb question for @DemiMarie — per your PR/remediation, will CUPS even still exist in the services menu Marek described, above? If "yes," then this sounds like a very simple 2-sentence "How To" blab in the docs.

It isn’t present as an entry that can be checked, but it is easy to add. That said, the lack of discoverability is a serious problem.

Ok, so then what needs to be done to make the entry visible in the settings panel? If it could be spelled-out so that a less fancy person can then compose a docs entry, that'd be great. That sounds like the one missing piece to a simple "How To" entry in the docs.

[tasket]

For people having trouble picking out the correct way to enable printing:

Enable Printing Howto:

in VM settings - go to "services" tab, select "cups" from the drop-down and click "add".