** Changed in: ltsp (Ubuntu)
Status: New => Invalid
** Changed in: ltsp (Ubuntu)
Assignee: (unassigned) => Scott Balneaves (sbalneav)
--
Karmic - Webcam does not work as a ltsp-localapps
https://bugs.launchpad.net/bugs/487473
You received this bug notification because you are a membe
Well, I did it in short way - ltsp-build-client --arch i386
Now webcam works in both servers. My bad, I'm sorry for that.
as...@edubuntu:~$ cat /etc/group | grep ltsp001
adm:x:4:asmok,ltsp001
dialout:x:20:asmok,ltsp001
fax:x:21:ltsp001
cdrom:x:24:asmok,ltsp001
tape:x:26:ltsp001
audio:x:29:pulse,l
Well, I have another installation in KVM machine (Edubuntu DVD) and it
seems to work OK.
I removed all users in trouble one and created new 'ltsp001' user.
Webcam does not work.
Here are details for working on installation.
admin-edubu...@edubuntu:~$ cat /etc/group | grep ltsp001
adm:x:4:admin-e
You need write access on that device, so you need 666 or 777 because you
are not in video group.
r...@ltsp200:~# chmod 666 /dev/video*
r...@ltsp200:~# ls -al /dev/video*
crw-rw-rw- 1 root video 81, 0 2009-11-25 12:44 /dev/video0
r...@ltsp200:~#
Best Regards Asmo Koskinen.
--
Karmic - Webcam do
as...@edubuntu:~$ cat /opt/ltsp/i386/etc/group | grep video
video:x:44:
as...@edubuntu:~$
as...@edubuntu:~$ cat /opt/ltsp/i386/etc/group | grep ltsp001
as...@edubuntu:~$
r...@ltsp202:~# cat /etc/group | grep ltsp001
sambashare:x:120:asmok,ltsp001,ltsp002,ltsp003
ltsp001:x:1001:ltsp001
r...@ltsp20
with these permissions the device should be accessible, does the chroot have a
video group and do the GIDs match ?
using 777 is definately adding a huge security hole, you should not do that.
there seems to be a discrepancy between server and client in the group numbers.
(anyway the only proper
My users are in group video.
as...@edubuntu:~$ cat /etc/group | grep video
video:x:44:ltsp001,ltsp002,ltsp003
as...@edubuntu:~$
'ltsp-localapps guvcview' does not work. But if I do this in chroot,
after that 'ltsp-localapps guvcview' works.
r...@ltsp202:~# ls -al /dev/video*
crw-rw 1 root v
this is due to missing dbus support between the clients system dbus and
the session dbus on the server. most device access in karmic is granted
through udev-acl by default which in turn needs proper dbus
communication. in karmic the old way to access devices through system
group membership should s