Bug 449974

(In reply to comment #0)
> First checks if port is open in firewall, if not offer the user
> to open the firewall. 
>
> T-Wiz has detected that printer port(s) was being blocked by firewall
> 
> Open standard printer port in firewall? [ Open port ] ( 631 )

I would love to be able to do this, but unfortunately it is not yet possible. 
If it were possible, it could be done in system-config-printer when enabling
sharing.  See bug #440469.

> One big scan on all network printing protocols and 
> displays the printer(s) if found to the user. 
> 
> User selects printer(s) from detected printer(s) list 
> and [ Add printer(s) ]

This seems to duplicate a lot of the 'New Printer' part of
system-config-printer.  The point of the trouble-shooter is to help diagnose
problems, not carry out routine tasks.  The exception to this is something like
enabling debugging, which is required for analysis of the test page print --
there, we need to actually perform that task there and then.

For other things I think it is better to primarily point the user to the right
tool to use, so that they know in future what they need to do, and as a
convenience provide a button to launch the relevant tool if possible.

Other ideas look good in general.

I'm not so sure about moving the 'choose printer' screen.  The kinds of problems
we can deal with can be sorted into these categories:

* Can't print to a particular queue for some reason

* Queue doesn't exist for some reason

* Clients can't print to *this* print server

So I was sort of thinking that we could the first screen after the intro check
whether sharing is enabled and we have any printers shared, and use that to
deduce that this machine is acting as a print server.  Then it could check the
firewall rules etc.

If it is not a print server, that screen (and dependent screens) could be
skipped, and we'd go straight to the 'choose printer' screen.

Can you expand on your 4 options?  That sounds like it might be a useful
alternative approach, but I'm not quite sure what the screen would look like
where the user chooses between the 4 options.

Regarding the firewall is it not possible to 
grep the necessery rule from /etc/sysconfig/iptables 
then launch system-config-firewall encase the 
rule does not exist and skip all the port openings...

Troubleshooter wizard has detected the firewall
is blocking the necessary printer port.

Open system config [ Firewall ]

                       [ Quit ]

It's hack but it could do until bug #440469 gets solved

Not generally -- that file is not world-readable. (And no, you can't add a
helper application to read it as root, since that defeats the intentional 'not
world-readable' policy.)

To be honest it was a spur of the moment thing I did not research it
in any way or form. 

What was going through my head was, it was better then 
iptables -L | grep and since s-c-f could do why not s-c-p.

It was an temporary hack suggestion. 

Created attachment 308423 [details]
Cups-sanity-check 

This is as I see the cups sanity check would be.

Which is the first thing the troubleshooter does when user clicks forward. 
( Before he enters the 4 option menu or in current case the choose printer
window )

If he detect that cups is not running he will enable it when user
clicks done and drops the user back to printer config.

( The apply button on the picture. I did not find any done button, if using
an apply button we need it's counter part the cancel button )

There also needs to be some action taken if the troubleshooter
is unable to start the cups daemon debugging maybe?.

The troubleshooter runs as a user process, and is not able to start/stop
services.  It is able to launch /usr/bin/system-config-services; however, it
seems to me that if the CUPS server is not running then it is for one of two
reasons:

1. The user disabled it themselves, and so they know how to re-enabled it again
2. cupsd died, in which case there is some other problem to diagnose

Can you expand on your 4 options?  I'm still not clear what the 4 options you
propose are.

"1. The user disabled it themselves, and so they know how to re-enabled it again"

The cups daemon should be off by default hence if the user has not enabled it 
when he connects the printer he would be noted to do so there.

"2. cupsd died, in which case there is some other problem to diagnose"

Which I think should be in the hand of the troubleshootin wizard 
look for something obvious ( permission errors selinx, etc ) if unable to 
"solve" or hint to the user what to "solve" he should copy the cups log 
( or asking him to copy /var/log/messages and /var/log/cups/*_log )
to the users desktop and ask him to file a bug report or send an email
containing the logs as an attachements to the fedora-test-list or the
fedora-users-list.

First set aside all your knowledge on printing in gnu/linux 
and set your self in the shoes of an elderly person or a child.. 
Basically a person with little to no knowledge of computers and is connecting a
printer which then seeks the help of the troubleshooter wizard, which he then
expects fix the problem. 

Troubleshooter wizard is for people with no knowledge of computers

Throwing debug output to the person that is using the troubleshooting
wizard is like putting some one in a fighter-jet and expecting him to fly it. 

If a person knows what he's doing he would not need the wizard in the 
first place, He would know how to enable debugging where to get the information
and so on... 

My four options are ( was going to do some window drawings ) 
hope this clears it up.

Option 1.

Is your printer connected to the computer? [ Scan ]

Check if cups running, check if kernel detects printer - inform user ( with
pictures ) to make sure it's switched on and all wires are correctly connected
then offer to  check again..

This option addresses commonly known problem with connecting and adding 
a new printer issues.

1. Are the necessary service running so the printer can be setup.
2. Has the end user correctly connected the printer to the computer.
3. Does the OS detect the printer. ( Drivers, which btw in our case the user is
fucked if it does not )

See User choose option 1 for further detail.

Option 2.
 
( Relies heavy on T-wiz to be able to open or check for printer
ports in firewall very common cause... )

Is your printer connected on a network? [ Scan ]
( check cups running - check for network connectivity - check firewall - send
one big scan which contains all the prototols - hope for reply on any of them )

This option addresses commonly known problem with connecting and adding 
a network connected printer issues.

1. Are the necessary service running so the printer can be setup.
2. Does the computer have network connectivity.
3. Is the firewall blocking the printer application from reaching printers on
the network
4. Has the user been setting up a printer on IPP for example while the printer
is on a windows network. 

See User choose option 2 for further details.

Option 3.

Troubleshoot printer
( Display any errors received from the printer ask user to perform certain
action if needed like adding papper/ink etc)

This option addresses commonly known problem with the printer himself ( HW ).

1. Is the paper jammed.
2. Is the printer out of ink ( which color )
3. Is the printer out paper
4. More errors..

So choose printer should show...

Name = Que name
Location = Location as in cups web interface. 
Information = Make/Model/Printer Driver
Status = Printer State: as in cups web interface/Error msg from printer.
( Dont know how intellect the Printer State: is in cups ) 

Option 4.

Troubleshoot printing from application.

This option addresses commonly known problem while printing from an application
( SW ) ( Usually wrong settings either in app or on the printer configuration ).

1. User cant print from an application 
2. Paper size incorrect 
3. Wrong type of paper.
4. User cant print in color.
5. And the list can go on.

(In reply to comment #7)
> "1. The user disabled it themselves, and so they know how to re-enabled it again"
> 
> The cups daemon should be off by default hence if the user has not enabled it 
> when he connects the printer he would be noted to do so there.

Huh?  Of course it shouldn't be off by default.

> "2. cupsd died, in which case there is some other problem to diagnose"
> 
> Which I think should be in the hand of the troubleshootin wizard 
> look for something obvious ( permission errors selinx, etc )

My point is that simply starting the server again is not something that the
troubleshooter should do.

> Throwing debug output to the person that is using the troubleshooting
> wizard is like putting some one in a fighter-jet and expecting him to fly it.

I would gladly get the trouble-shooter to file a bug report itself as with
launchpad in Ubuntu -- however, it's not clear how to do this with Bugzilla, and
there needs to be some mechanism for feedback.

The troubleshooter is still in early stages of development, and is a useful way
for me to quickly ask for exactly which debugging output I need.  In the future,
when the rest of it is actually implemented, I hope it will be able to do much
more to identify problems on its own and suggest solutions.  The last resort,
however, will always be to save a debug file and have the user call for support.

If it helps, we could always hide the actual debug messages behind an
'Advanced>>' widget, or just not show them in the user interface and only
provide a 'Save' button.  But we have to be able to collect that diagnostic
output somehow because a program will not always be able to fix the problem.

> If a person knows what he's doing he would not need the wizard in the 
> first place, He would know how to enable debugging where to get the information
> and so on... 

This isn't quite true actually.  I spend a lot of my time asking for cups debug
logs, as it seems that no-one know how to do that.

> My four options are ( was going to do some window drawings ) 
> hope this clears it up.

So, summarising it:

> Is your printer connected to the computer? [ Scan ]
 
> Is your printer connected on a network? [ Scan ]

> Troubleshoot printer

> Troubleshoot printing from application.

I can't really see how that makes any sense in a dialog on its own -- what am I
supposed to do if I want to 'troubleshoot printer' *and* the computer is
connected to this computer?

How is the user supposed to know if the problem is with the application or with
the printer?

IMHO, it makes a lot more sense to narrow things down bit by bit:
* First, see if the queue the user wants actually exists; if it doesn't, try to
find out why that is
* Second, see if it is a network printer and look for network problems
* Third, see if we can print a test page to it
* etc

This is in fact exactly what we currently do, but there are many holes to fill in.

In particular, if the queue doesn't exist for a local printer we just give up,
but I plan to have a 'Plug in the printer now' page, which watches for changes
in the CUPS device list, etc.  We do already make a list of the connected USB
printer devices for the diagnostic output, as well as checking USB device
permissions, but there is no user interface to act on it yet.

For network printers we do things like checking remote firewalls and looking for
mis-configured CUPS servers.  We also run traceroute, but this just goes into
the diagnostic output and is not acted on yet.

For things like the printer being out of paper, well we have a bit of a user
interface for that in the trouble-shooter, but really it needs to be handled
"like normal".  We don't want people to have to run the trouble-shooter every
time they run out of paper or ink.  In Fedora 9 we are able to display a
notification bubble to the user who submitted the job, telling them the printer
is out of paper or ink or has some other problem.  Paper-out detection works for
all locally-connected USB printers, and ink detection works for all HPLIP
queues.  Work is continuing on extending that support.

I really want that sort of thing to be "the normal case", and not something that
needs a trouble-shooter.

For networked CUPS/IPP printers, we already sanity-check them for being enabled,
accepting jobs, having printer errors etc.

The other cases you list:

1. User can't printer from a particular application

This is meant to be handled by the existing 'Print Test Page' screen, although
perhaps it isn't clear enough.  You don't have to submit an actual CUPS test
page there -- you can just print from the application you are having trouble with.

2. Paper size incorrect

As noted in bug #449802 :-)

3. Wrong type of paper.

This is an interesting one, and I hadn't thought of it.  Great idea.

4. User can't print in colour, or in sufficient resolution, or with duplexing,
or "missing feature X"

Yes, I've given this a little bit of thought.  I was hoping to add a screen to
guide the user through trying out different drivers that may be available for
the printer.  Many printer models can be driven by e.g. hpijs, gutenprint,
various ghostscript drivers, or perhaps PostScript.  Some way of trying them
each out and selecting the best one would be great.

What would *really* rock would be a way to feed the results back to the
openprinting.org database. :-)

Thanks for your useful feedback; no-one else has paid much attention to the
trouble-shooter. ;-)

Think I've covered all the points now in these trac entries:

https://fedorahosted.org/system-config-printer/ticket/40
https://fedorahosted.org/system-config-printer/ticket/41
https://fedorahosted.org/system-config-printer/ticket/42
https://fedorahosted.org/system-config-printer/ticket/43