Hoy he instalado una grabadora de DVD. Tenia una grabadora de CD y lectora de DVD que quiero conservar, porque va más rápido. Ahora además hay la grabadora de DVD. Primero la nueva estaba com /dev/hdd (la de antes como /dev/hdc). K3b no la reconocia, así que he cambiado el orden y la nueva está en /dev/hdc. K3b la ha visto y funciona, he hecho copia de seguridad de los ~/ en DVD. SuSE Plugger ha detectado todos los cambios y ha pedido los puntos de montaj. Le he dejado escoger y lo ha dejado así Device: /dev/hdc Link: /dev/dvdram Mount Point: /media/dvdram Device: /dev/hdc Link: /dev/cdrecorder Mount Point: /media/cdrecorder El /etc/fstab ha quedado así: (...) /dev/cdrecorder /media/cdrecorder subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 (...) /dev/dvdram /media/dvdram subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 /dev/cdrom /media/cdrom subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 (no se porque también ha creado el /dev/cdrom ... al tener un CD montado, se ve lo mismo en los dos lugares) $ ls -l /dev/dvdram /dev/cdrom /dev/cdrecorder lrwxrwxrwx 1 root root 3 2004-08-10 00:11 /dev/cdrecorder -> hdd lrwxrwxrwx 1 root root 3 2004-08-10 00:11 /dev/cdrom -> hdc lrwxrwxrwx 1 root root 3 2004-08-10 00:11 /dev/dvdram -> hdc ls -l /dev/hdc /dev/hdd brw------- 1 benjami disk 22, 0 2004-04-06 15:27 /dev/hdc brw-rw---- 1 root disk 22, 64 2004-04-06 15:27 /dev/hdd Éste ultimo es el que no reconoce como grabadora. Veo que tiene propietario y permisos distintos. Por otra parte, al ir a la configuración de k3b y entrar el nuevo dispositivo (/dev/hdd) no lo acepta y en el /var/log/messages hay esto: Aug 10 00:49:00 itaca k3b: resmgr: server response code 502 No encuentro el motivo para que /dev/hdd no pueda trabajar como grabadora. Os paso la información de arriba por si los expertos en hardware me podéis orientar :) -- Benjamí http://weblog.bitassa.net .
Benjamí Villoslada wrote:
Hoy he instalado una grabadora de DVD. Tenia una grabadora de CD y lectora de DVD que quiero conservar, porque va más rápido. Ahora además hay la grabadora de DVD.
Primero la nueva estaba com /dev/hdd (la de antes como /dev/hdc). K3b no la reconocia, así que he cambiado el orden y la nueva está en /dev/hdc. K3b la ha visto y funciona, he hecho copia de seguridad de los ~/ en DVD.
SuSE Plugger ha detectado todos los cambios y ha pedido los puntos de montaj. Le he dejado escoger y lo ha dejado así
Device: /dev/hdc Link: /dev/dvdram Mount Point: /media/dvdram
Device: /dev/hdc Link: /dev/cdrecorder Mount Point: /media/cdrecorder
El /etc/fstab ha quedado así:
(...)
/dev/cdrecorder /media/cdrecorder subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0
(...)
/dev/dvdram /media/dvdram subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 /dev/cdrom /media/cdrom subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0
(no se porque también ha creado el /dev/cdrom ... al tener un CD montado, se ve lo mismo en los dos lugares)
$ ls -l /dev/dvdram /dev/cdrom /dev/cdrecorder lrwxrwxrwx 1 root root 3 2004-08-10 00:11 /dev/cdrecorder -> hdd lrwxrwxrwx 1 root root 3 2004-08-10 00:11 /dev/cdrom -> hdc lrwxrwxrwx 1 root root 3 2004-08-10 00:11 /dev/dvdram -> hdc
ls -l /dev/hdc /dev/hdd brw------- 1 benjami disk 22, 0 2004-04-06 15:27 /dev/hdc brw-rw---- 1 root disk 22, 64 2004-04-06 15:27 /dev/hdd
Éste ultimo es el que no reconoce como grabadora. Veo que tiene propietario y permisos distintos.
Por otra parte, al ir a la configuración de k3b y entrar el nuevo dispositivo (/dev/hdd) no lo acepta y en el /var/log/messages hay esto:
Aug 10 00:49:00 itaca k3b: resmgr: server response code 502
No encuentro el motivo para que /dev/hdd no pueda trabajar como grabadora. Os paso la información de arriba por si los expertos en hardware me podéis orientar :)
Configuraste los puentes en la parte posterior de ambas, para que una quede como master y la otra slave?
On Mon, 09 Aug 2004 22:59:05 -0300, Juan Erbes wrote:
Benjamí Villoslada wrote:
Configuraste los puentes en la parte posterior de ambas, para que una quede como master y la otra slave?
Sí. Ya está solucionado, pero me gustaria saber más :) Ayer decía:
ls -l /dev/hdc /dev/hdd brw------- 1 benjami disk 22, 0 2004-04-06 15:27 /dev/hdc brw-rw---- 1 root disk 22, 64 2004-04-06 15:27 /dev/hdd
Éste ultimo es el que no reconoce como grabadora. Veo que tiene propietario y permisos distintos.
Dejé hdd (que no funcionaba como grabadora) con el mismo propietario y permisos que hdc (que sí funcionaba como grabadora). A partir de ahí funcionó como grabadora (como lectora lo hizo siempre). También SuSE Plugger empezó a lanzar los mensajes de discos vírgenes/con datos montados para abrir k3b y Konqueror (antes no lo hacía). Las preguntas son: - A qué grupo pertenecía hdd para que pudiese leer de la grabadora pero no grabar --cuando el permiso de grabación para el grupo estaba activo. ls (arriba está) no dice el grupo :? - Si la grabadora es de benjami ningun usuario más podrá trabajar con ella, no está mejor que sea de root y un grupo "grabadores" con permiso de escritura? -- Benjamí http://weblog.bitassa.net .
On Tue, 10 Aug 2004 15:21:56 +0200, Benjamí Villoslada wrote:
- A qué grupo pertenecía hdd para que pudiese leer de la grabadora pero no grabar --cuando el permiso de grabación para el grupo estaba activo. ls (arriba está) no dice el grupo :?
Error: pertenece a disk. Pero es una buena precaución de seguridad no añadir a ningun usuario a disk: http://adam.rosi-kessel.org/weblog/free_software/code/cautionary.html
- Si la grabadora es de benjami ningun usuario más podrá trabajar con ella, no está mejor que sea de root y un grupo "grabadores" con permiso de escritura?
Eso me lo sigo preguntando. Y cómo el usuario benjamí leía de una grabadora de root y del grupo disk sin estar en disk --seguro que tiene respuesta obvia... porque root lo monta para todos los usuarios? Todavia no conozco el hotplug y automount :) -- Benjamí http://weblog.bitassa.net .
El 2004-08-10 a las 15:44 +0200, Benjamí Villoslada escribió:
- Si la grabadora es de benjami ningun usuario más podrá trabajar con ella, no está mejor que sea de root y un grupo "grabadores" con permiso de escritura?
Eso me lo sigo preguntando. Y cómo el usuario benjamí leía de una grabadora de root y del grupo disk sin estar en disk --seguro que tiene respuesta obvia... porque root lo monta para todos los usuarios? Todavia no conozco el hotplug y automount :)
Estoy soñoliento, así que no voy a mirarlo ahora ;-) -- pero al abrir una sesión gráfica (kde, gnome, etc) los permisos de ciertos dispositivos pasan a ser propiedad del usuario que haya abierto esa sesión. Para dejarlos fijos (y jugar con los propietarios de los grupos, al estilo tradicional) hay que desactivar ese comportamiento. Eso era... que no recuerdo... ah, '/etc/resmgr.conf' - que recordarás que te dió un error 502 al principio. Ese numero de error (más o menos) me suena haberlo visto por la lista hace bastantes meses. -- Saludos Carlos Robinson
Carlos, una pregunta relacionada: si tiene tela, abro otro hilo: ¿sabes o sabe alguien si tocando ese archivo '/etc/resmgr.conf' se puede resolver el comportamiento de arts, que al entrar un segundo usuario en KDE, por ejemplo, no puede acceder a los dispositivos de sonido porque los tiene el primero que entró para el solito? -- _ |_)_ o|_ _ | | (/_||_)(_)| Carlos E. R. escribió:
El 2004-08-10 a las 15:44 +0200, Benjamí Villoslada escribió:
- Si la grabadora es de benjami ningun usuario más podrá trabajar con ella, no está mejor que sea de root y un grupo "grabadores" con permiso de escritura?
Eso me lo sigo preguntando. Y cómo el usuario benjamí leía de una grabadora de root y del grupo disk sin estar en disk --seguro que tiene respuesta obvia... porque root lo monta para todos los usuarios? Todavia no conozco el hotplug y automount :)
Estoy soñoliento, así que no voy a mirarlo ahora ;-) -- pero al abrir una sesión gráfica (kde, gnome, etc) los permisos de ciertos dispositivos pasan a ser propiedad del usuario que haya abierto esa sesión. Para dejarlos fijos (y jugar con los propietarios de los grupos, al estilo tradicional) hay que desactivar ese comportamiento. Eso era... que no recuerdo... ah, '/etc/resmgr.conf' - que recordarás que te dió un error 502 al principio. Ese numero de error (más o menos) me suena haberlo visto por la lista hace bastantes meses.
El 2004-08-15 a las 12:56 +0200, Peibol escribió:
Carlos, una pregunta relacionada: si tiene tela, abro otro hilo:
Por lo menos, le voy a cambiar el título, que es menos malo ;-)
¿sabes o sabe alguien si tocando ese archivo '/etc/resmgr.conf' se puede resolver el comportamiento de arts, que al entrar un segundo usuario en KDE, por ejemplo, no puede acceder a los dispositivos de sonido porque los tiene el primero que entró para el solito?
Claro, tiene sentido. Mira, el fichero tiene estas lineas: class desktop # Standard multimedia devices add /dev/audio desktop add /dev/mixer desktop add /dev/dsp desktop add /dev/sequencer desktop add /dev/video desktop Luego, más abajo, define quienes son el grupo 'desktop': allow desktop tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:0 Tendrías que comentar las lineas de los chismes de audio. Luego tendrías que asignarles un usuario y grupo a esos dispositivos, y ver si permanecen o alguien más los cambia; me sospecho que habría que ponerlos en el /etc/permissions.local también. Ahora, ¿que grupo? La elección lógica sería "audio" precisamente. Ahora bien, que eso funcionase bien, pues también dependería de que los dispositivos se abriesen con derechos exclusivos - aquí estoy entrando en un terreno que desconozco con precisión el Linux. Se supone que si abres el kde o el gnome, el sonido es gestionado por un demonio que coge los dispositivos, y les envia los sonidos tratados que quieren enviar los programas. Si abres dos sesiones, no tiene sentido que ambas arranquen sendos demonios, sino que el demonio debería ser externo, y ambas sesiones usar el demonio ya arrancado. No se si me explico :-? Porque eso no se bien como se logra, ni si se puede lograr. Luego está el detalle de que un 'arts' admita dos usuarios concurrentes. No se si se pueden tener dos arts abiertos, pero es conceptualmente absurdo, que es lo que vengo a decir arriba. -- Saludos Carlos Robinson
"No se si me explico :-? Porque eso no se bien como se logra, ni si se puede lograr."
Te explicas, pero el caso de más de un usuario en un PC no es descabellado: en mi casa somos dos a usar el PC. Lo práctico es dejar sesión abierta y abrir una nueva para el otro usuario. ¿Cómo lo solucioné yo? Desconectando arts y me di cuenta que basta con poner en el cron un script que cambie los permisos de /dev/mixer y /dev/dsp a escritura para todos, que se lanza cada 5 ó 6 minutos, y así me ahorro problemas de quién entra primero o que secuencias de "usuario X - inicio de sesión - fin de sesión" se hace. Los programas multimedia los tengo puestos que usen directamente OSS, y va fino, aunque no creo que me diera problemas que usaran ALSA. La pregunta iba por si en vez del tinglado del cron hay una solución más "elegante". Peibol. Carlos E. R. escribió:
El 2004-08-15 a las 12:56 +0200, Peibol escribió:
Carlos, una pregunta relacionada: si tiene tela, abro otro hilo:
Por lo menos, le voy a cambiar el título, que es menos malo ;-)
¿sabes o sabe alguien si tocando ese archivo '/etc/resmgr.conf' se puede resolver el comportamiento de arts, que al entrar un segundo usuario en KDE, por ejemplo, no puede acceder a los dispositivos de sonido porque los tiene el primero que entró para el solito?
Claro, tiene sentido. Mira, el fichero tiene estas lineas:
class desktop # Standard multimedia devices add /dev/audio desktop add /dev/mixer desktop add /dev/dsp desktop add /dev/sequencer desktop add /dev/video desktop
Luego, más abajo, define quienes son el grupo 'desktop':
allow desktop tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:0
Tendrías que comentar las lineas de los chismes de audio. Luego tendrías que asignarles un usuario y grupo a esos dispositivos, y ver si permanecen o alguien más los cambia; me sospecho que habría que ponerlos en el /etc/permissions.local también. Ahora, ¿que grupo? La elección lógica sería "audio" precisamente.
Ahora bien, que eso funcionase bien, pues también dependería de que los dispositivos se abriesen con derechos exclusivos - aquí estoy entrando en un terreno que desconozco con precisión el Linux. Se supone que si abres el kde o el gnome, el sonido es gestionado por un demonio que coge los dispositivos, y les envia los sonidos tratados que quieren enviar los programas. Si abres dos sesiones, no tiene sentido que ambas arranquen sendos demonios, sino que el demonio debería ser externo, y ambas sesiones usar el demonio ya arrancado.
No se si me explico :-? Porque eso no se bien como se logra, ni si se puede lograr.
Luego está el detalle de que un 'arts' admita dos usuarios concurrentes. No se si se pueden tener dos arts abiertos, pero es conceptualmente absurdo, que es lo que vengo a decir arriba.
El 2004-08-18 a las 19:09 +0200, Peibol escribió:
La pregunta iba por si en vez del tinglado del cron hay una solución más "elegante".
Claro que si, eso es lo que te conté del fichero '/etc/resmgr.conf'. Lo que haces con el cron es la parte que te conté que si que sabía. Vuelve a leerte mi mensaje. -- Saludos Carlos Robinson
On Sun, 15 Aug 2004 02:35:39 +0200 (CEST), Carlos E. R.
El 2004-08-10 a las 15:44 +0200, Benjamí Villoslada escribió:
- Si la grabadora es de benjami ningun usuario más podrá trabajar con ella, no está mejor que sea de root y un grupo "grabadores" con permiso de escritura?
Eso me lo sigo preguntando. Y cómo el usuario benjamí leía de una grabadora de root y del grupo disk sin estar en disk --seguro que tiene respuesta obvia... porque root lo monta para todos los usuarios? Todavia no conozco el hotplug y automount :)
Estoy soñoliento, así que no voy a mirarlo ahora ;-) -- pero al abrir una sesión gráfica (kde, gnome, etc) los permisos de ciertos dispositivos pasan a ser propiedad del usuario que haya abierto esa sesión. Para dejarlos fijos (y jugar con los propietarios de los grupos, al estilo tradicional) hay que desactivar ese comportamiento. Eso era... que no recuerdo... ah, '/etc/resmgr.conf' - que recordarás que te dió un error 502 al principio. Ese numero de error (más o menos) me suena haberlo visto por la lista hace bastantes meses.
Gracias! Veo que en /etc/resmgr.conf hay cosas interesantes. De momento funcionan las dos grabadoras a base de tocar los permisos de hdd: brw------- 1 benjami disk 22, 0 2004-04-06 15:27 /dev/hdc brw-rw---- 1 root disk 22, 64 2004-04-06 15:27 /dev/hdd Ahora es como benjami :) Me preguntaba porqué el sistema lo había cambiado con hdc pero no con hdd. Ahora veo que el dispositivo /dev/dvdram no está en /etc/resmgr.conf, puede que sea el motivo. Haré pruebas. PS: El error 502 no me sucedió a mi... de hecho, no conocia el resmgr, me extraña... lo usan pocas distribuciones? -- Benjamí http://weblog.bitassa.net .
On Sun, 15 Aug 2004 20:45:15 +0200, Benjamí Villoslada wrote:
PS: El error 502 no me sucedió a mi... de hecho, no conocia el resmgr, me extraña... lo usan pocas distribuciones?
Rectifico: era yo. Hace dias y no recordaba que lo había pasado en el /var/log/messages ... 8-) No relacioné el mensaje con el resmgrd y buscaba por otras partes. Es un daemon importante, lo tendré en cuenta. Se habla poco de él incluso en listas con mucho tráfico como bulmailing (la mayoría allí usa Debian), por eso preguntaba si está o no muy extendido. -- Benjamí http://weblog.bitassa.net .
El 2004-08-15 a las 20:54 +0200, Benjamí Villoslada escribió:
PS: El error 502 no me sucedió a mi... de hecho, no conocia el resmgr, me extraña... lo usan pocas distribuciones?
Rectifico: era yo. Hace dias y no recordaba que lo había pasado en el /var/log/messages ... 8-)
No relacioné el mensaje con el resmgrd y buscaba por otras partes. Es un daemon importante, lo tendré en cuenta. Se habla poco de él incluso en listas con mucho tráfico como bulmailing (la mayoría allí usa Debian), por eso preguntaba si está o no muy extendido.
Pues no estoy seguro, pero es parte del sistema de seguridad pam, y los tiros van por ahí. Pero el pam es un gran desconocido, eso explica porque se comente poco, y que cuando ocurre algo pocos tienen claro como se soluciona. -- Saludos Carlos Robinson
participants (4)
-
Benjamí Villoslada -
Carlos E. R. -
Juan Erbes -
Peibol