Bug 446143 - xsane: device not found when invoke from remote vnc
xsane: device not found when invoke from remote vnc
Status: CLOSED DUPLICATE of bug 452156
Product: Fedora
Classification: Fedora
Component: vnc (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-12 20:21 EDT by eric magaoay
Modified: 2013-04-30 19:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-21 10:54:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description eric magaoay 2008-05-12 20:21:35 EDT
Description of problem:
When the primary server console boot up through init level 3, and then invoking
"xsane" through remote vnc (vncviewer) it fails to find the scanner (error:
"device not found"). Problem does not occur when server console boots up to init
level 5. 

It should work at init level 3 since server can be headless and often times
viewed from remote clients.

Version-Release number of selected component (if applicable):
sane-backends.x86_64 1.0.19-10.fc9
sane-backends-devel.x86_64 1.0.19-10.fc9
sane-backends-libs.x86_64 1.0.19-10.fc9
sane-backends-libs-gphoto2.x86_64 1.0.19-10.fc9
sane-frontends.x86_64 1.0.14-4.fc9

How reproducible:
persistent

Steps to Reproduce:
1. reboot server console to init level 3
     vi /etc/inittab 
          id:3:initdefault:
2. access server thru remote client viewer (vncviewer) tunnel through ssh 
   assumed remote client viewer is a fedora linux (any vnc will do)
   i.e. ssh -f -L 15922:localhost:5922 user22@192.168.3.22 \
           'vncserver -kill :22 ; vncserver :22 -localhost ; sleep 5'; \ 
           sleep 5 ; vncviewer localhost::15922
3. once logged in as a regular user (user22) from remote client viewer, execute
"xsane"
  
Actual results:
output: "Device not Found"

Expected results:
should be able to detect scanning device.

Additional info:
* Will work when server primary console start at init level 5.
* Will also work if the device driver permission is set to:
    chmod 666 /dev/bus/usb/003/002
  or set group ownership (users) 
    chgrp users /dev/bus/usb/003/002
    chmod 660 /dev/bus/usb/003/003
* The above alternative solution is probably not advisable for non-tech users
Comment 1 Nils Philippsen 2008-05-13 05:57:51 EDT
When logged in through VNC (and not locally), what is the output of the command
`ck-list-sessions`?
Comment 2 eric magaoay 2008-05-14 03:48:57 EDT
[adm2@mazatlan2 ~]$ ck-list-sessions
Session1:
	uid = '500'
	realname = ''
	seat = 'Seat2'
	session-type = ''
	active = FALSE
	x11-display = ':32'
	x11-display-device = ''
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-14T06:28:05Z'
Comment 3 Nils Philippsen 2008-05-14 05:34:33 EDT
Hmm, I suspect that you're logged into X11 locally because I made a VNC session
as you described in comment #0 and didn't get a separate ConsoleKit session for
the VNC display... Please attach the output of ck-list-sessions again (cf.
comment #1) as well as the value of $DISPLAY in VNC. Thanks.
Comment 4 Bug Zapper 2008-05-14 07:04:06 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 eric magaoay 2008-05-14 15:14:49 EDT
Since vncviewer is being securedly tunneled through ssh, so it should make it
look like you are logged in locally. 

Here let me try again:
NOTES:
* acapulco3 => remote pc (vnc viewer)
* mazatlan2 => local pc (scanner attached)
* acapulco3 vnc viewing mazatlan2 through port 6064 (display translate to :164)
and being securely tunneled through port 16064
* ssh => default Port changed from 22 to 6602 
         (modified from /etc/ssh/sshd_config)

From remote PC:
==============
[adm3@acapulco3 ~]$ ssh -p 6602 -f -L 16064:localhost:6064 adm2@192.168.3.102
'vncserver -kill :164;vncserver :164 -localhost; sleep 5'; sleep 5; vncviewer
localhost::16064 -geometry 1024x760
adm2@192.168.3.102's password:
Killing Xvnc process ID 12550

New 'mazatlan2:164 (adm2)' desktop is mazatlan2:164

Starting applications specified in /home/adm2/.vnc/xstartup
Log file is /home/adm2/.vnc/mazatlan2:164.log

viewed from VNC, logged into local pc(where scanner is attached): 
===============================================================
[adm2@mazatlan2 ~]$ ck-list-sessions
Session5:
	uid = '500'
	realname = ''
	seat = 'Seat5'
	session-type = ''
	active = FALSE
	x11-display = ':164'
	x11-display-device = ''
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-14T16:42:07Z'
Session2:
	uid = '0'
	realname = 'root'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-14T07:59:08Z'
	idle-since-hint = '2008-05-14T16:36:24Z'
Session1:
	uid = '500'
	realname = ''
	seat = 'Seat2'
	session-type = ''
	active = FALSE
	x11-display = ':32'
	x11-display-device = ''
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-14T06:28:05Z'
[adm2@mazatlan2 bugs]$ echo $DISPLAY
:164.0

NOTE: Session1=> another remote pc(windows) vnc connect through port 5932 
      Session2=> primary local console(mazatlan2) logged in as root
      Session5=> remote pc(acapulco3) vnc connect through port 6064
Comment 6 Nils Philippsen 2008-05-15 09:10:53 EDT
(In reply to comment #5)
> Since vncviewer is being securedly tunneled through ssh, so it should make it
> look like you are logged in locally. 

Whether or not that should make a difference is debatable ;-).

> Session1:
> 	uid = '500'
> 	realname = ''
> 	seat = 'Seat2'
> 	session-type = ''
> 	active = FALSE
^^^^^^^^^^^^^^^^^^^^^^

There's the rub, as long as the session isn't active, your user wouldn't get the
necessary ACLs on the device file.

> 	x11-display = ':32'
> 	x11-display-device = ''
> 	display-device = ''
> 	remote-host-name = ''
> 	is-local = TRUE
> 	on-since = '2008-05-14T06:28:05Z'
> [adm2@mazatlan2 bugs]$ echo $DISPLAY
> :164.0
> 
> NOTE: Session1=> another remote pc(windows) vnc connect through port 5932 
>       Session2=> primary local console(mazatlan2) logged in as root
>       Session5=> remote pc(acapulco3) vnc connect through port 6064

In conclusion, I think this is a matter of making VNC sessions active ConsoleKit
sessions. How and if that should be done is the call of the VNC maintainer IMO,
therefore I'm reassigning the component.

In the meantime, you can use polkit-gnome-authorization to authorize the use of
scanners in non-active sessions (change the implicit authorizations in
org.freedesktop.hal.device-access.scanner).
Comment 7 eric magaoay 2008-05-16 14:02:17 EDT
For some reason even if the session (Session1-/dev/tty1) is NOT active, as long
as the local terminal (Session4-/dev/tty7) is logged in graphic mode (init 5),
as shown below, xsane can find the scanner device. 

Anyway, polkit-gnome-authorization is good workaround, which does not need a
local terminal to logged in graphic mode in order for xsane to find the scanning
device.

* Below xsane has no problem finding the scanner device
--------------------------------------------------------
[adm2@mazatlan2 ~]$ ck-list-sessions
Session2:
	uid = '0'
	realname = 'root'
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-16T15:18:53Z'
Session4:
	uid = '500'
	realname = ''
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty7'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-16T15:21:28Z'
Session1:
	uid = '500'
	realname = ''
	seat = 'Seat2'
	session-type = ''
	active = FALSE
	x11-display = ':32'
	x11-display-device = ''
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-16T15:18:00Z'
[adm2@mazatlan2 ~]$ 

* below shown when xsane CANNOT find scanner device
---------------------------------------------------
[adm2@mazatlan2 ~]$ ck-list-sessions
Session2:
	uid = '0'
	realname = 'root'
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-16T15:18:53Z'
	idle-since-hint = '2008-05-16T15:21:46Z'
Session1:
	uid = '500'
	realname = ''
	seat = 'Seat2'
	session-type = ''
	active = FALSE
	x11-display = ':32'
	x11-display-device = ''
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2008-05-16T15:18:00Z'
[adm2@mazatlan2 ~]$ 
--------------------------

Comment 8 Nils Philippsen 2008-05-19 05:52:09 EDT
(In reply to comment #7)
> For some reason even if the session (Session1-/dev/tty1) is NOT active, as long
> as the local terminal (Session4-/dev/tty7) is logged in graphic mode (init 5),
> as shown below, xsane can find the scanner device.

That makes sense if this is the same user -- as long as a user has one active
session, the ACLs on the device files are set appropriately.
Comment 9 Adam Tkac 2008-05-20 09:37:57 EDT
Would it be possible try what happen if you uncomment
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

lines in your ~/.vnc/xstartup, please?
Comment 10 eric magaoay 2008-05-21 16:08:28 EDT
The 2 lines were already uncommented when I reported the problem. Here is the
complete source:

~/.vnc/xstartup
==============================

#!/bin/sh
export PATH=$PATH:/usr/sbin:/sbin
vncconfig -iconic &
# Uncomment the following two lines for normal desktop:
 unset SESSION_MANAGER
 exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
gdm &

=============================
~                                          
Comment 11 Adam Tkac 2008-07-16 06:51:01 EDT
Hm, it seems this is duplicate of bug #452156. Would it be possible try patch
from https://bugzilla.redhat.com/show_bug.cgi?id=452156#c8, please? If you are
not able to apply/build it let me know. (Xsession and xinitrc-common files has
to be patched) Thanks
Comment 12 Adam Tkac 2008-07-21 10:54:09 EDT

*** This bug has been marked as a duplicate of 452156 ***
Comment 13 eric magaoay 2008-07-31 16:40:01 EDT
sorry I couldn't test this scanner at the this time due to somebody else
borrowing it. I will try to get it back if possible. 

I'm currently testing and using HP Photosmart C4280 All-in-one
(printer/scanner). Building from source at:
http://hplip.sourceforge.net/downloads.html
Scanning is working OK (version 2.8.7). I'm not sure about Fedora rawhide
(hplip, hplip-gui,libsane-hpaio) is working or not, but I know that F9 did not
work. I will submit a separate bug report if needed.

Note You need to log in before you can comment on or make changes to this bug.