Hay distintos escenarios:
Nota para todos los escenarios: Voy a utilizar la herramienta de Nautilus (clic derecho, opciones de comparticion) para compartir recursos, otra forma es modificar el archivo /etc/samba/smb.conf, pero aqui intento utilizar las herramientas provistas por Ubuntu 10.10
Escenario 1: Ubuntu 10.10 desktop y automunt.
Cuando se produce un automunt o desde el menu lugares, Ubuntu hace propietario del punto de montaje al usuario, y le asigna permisos de lectura
y escritura. Sin embargo los atributos para otros usuarios son nulos: -rw------- 1 sg sg
Si el sistema montado es ntfs, el volumen montado adopta los permisos y propietario que tenga el directorio utilizado como punto de montaje y no puede ser modificado luego con chmod ni chown, al menos al dia de hoy: http://es.wikipedia.org/wiki/NTFS-3G
Si se quiere compartir algun recurso en ese punto de montaje, es posible, pero solo será accesible remotamente con el mismo usuario que montó la particion.
Digamos que el usuario "sg" montó un disco extraible con formato ntfs, entonces podrá compartir algun directorio de ese volumen, pero solo sg podrá
accederlo remotamente.
El modo de hacerlo es agregar el usuario al sistema samba:
smbpasswd sg
El comando solicita la contraseña, la cual, no necesariamente, tiene que ser la del sistema linux, incluso puede quedar vacia.
Pude comprobar que, independientemente de la contraseña, si el usuario samba es el mismo que el usuario ubuntu, ubuntu lo acepta como el mismo usuario; con lo cual puede crear y modificar archivos.
Si necesito acceder remotamente con otro usuario, digamos "operador", ese ya es un problema pues, a pesar de que puedo crear el usuario en el sistema samba, no es posible cambiarle ni propietario ni atributos al volumen montado (ver mas arriba en negrita)
No encontré solucion para este escenario. Solo el usuario, sg en este caso, puede acceder remotamente.
Eso es un problema, ya que en una red en la que todos estan acostumbrados a acceder al recurso sin ingresar usuario y pass, ya que son "operador", se complica explicarle a cada uno que deberán ingresar el usuario sg para acceder al recurso.
Obviamente que no ocurre lo mismo con un directorio en sistema ext4 (ext3, etc), ya que linux sí permite asignar distintos propietarios y atributos al sistema de archivos nativo.
Escenario 2: Ubuntu 10.10 Desktop y montaje hecho por root desde consola o fstab:
Para resolver el problema del escenario 1 hice lo siguiente:
Como root creé un directorio de montaje llamado "Disco". Aqui el problema es que el propietario del recurso será root, pero lo resuelvo asignandole permisos totales para todos:
mkdir /media/Disco
chmod 777 /media/Disco/
Luego monté la particion ntfs:
mount /dev/sda4 -t ntfs-3g /media/Disco/
El parametro -t ntfs-3g puede obviarse pero en este caso lo dejo mas que nada para destacar el tipo de sistema que se esta montando.
Para automatizar el montaje desde fstab, hay que agregar la siguiente linea:
UUID=D82C26B52C268F16 /media/Disco ntfs-3g defaults
En donde el UUID se obtiene con el comando:
blkid /dev/sda4
El comando blkid esta explicado en el mismo fstab, bueno, al menos el fstab que trae ubuntu 10.10
Con esto, el sistema queda montado con permisos de lectura y escritura para cualquier usuario. Con lo que ahora tanto sg como operador y cualquier otro usuario, podran acceder remotamente y modificar libremente, siempre y cuando samba haya permitido el acceso.
Y justamente, aqui se presentó otro problema: Al ser propietario root del directorio utilizado como punto de montaje (/media/Disco), samba, por las politicas por defecto que tiene, no permitia compartir el recurso. El mensaje que da al intentar compartir es este:
La «red compartida» devolvió el error 255: net usershare add: cannot share path /media/VERBATIM/Public as we are restricted to only sharing directories we own.
Ask the administrator to add the line "usershare owner only = false"
to the [global] section of the smb.conf to allow this.
Por suerte, ademas del codigo de error, tambien da la solucion. Ojalá todo en Ubuntu o cualquier otro SO, fuera asi.
Solo bastó agregar la siguiente linea en la seccion [global] de /etc/samba/smb.conf:
usershare owner only = false
Y luego ejecutar:
restart smbd
Este ultimo comando, para mi fue una sorpresa, ya que estaba acostumbrado a hacer:
/etc/init.d/smbd restart
Por suerte, otra vez linux me auxilio, y no solo informó de un error al ejecutar ese comando, sino que sugirió el modo de hacerlo correctamente.
Escenario 3: El sistema del recurso a compartir es ext2, ext3, etc.
Bueno, aqui las cosas son simples. Ya mencioné que linux permite adaptar los permisos de estos recursos sin problemas.
domingo, 12 de diciembre de 2010
jueves, 9 de diciembre de 2010
Bug del Modo protegido de Internet Explorer 8
El modo protegido de internet explorer 8 solo funciona con sistemas operativos Windows Vista o versiones superiores.
Basicamente sirve para dar seguridad contra las vulnerabilidades. O sea, uno puede tener una vulnerabilidad pero el modo protegido evita que un codigo dañino pueda ejecutarse en nuestro equipo, sin importar la vulnerabilidad que se este aprovechando.
Me ocurrió que si intentaba imprimir una pagina web a un archivo, digamos, por ejemplo, mediante la impresora virtual tinypdf, el documento no se guardaba como era de esperar.
Sin embargo, al intentar imprimir nuevamente, el asistente para guardar el archivo, dejaba ver el archivo anterior "perdido". O sea, el archivo estaba pero no estaba. El unico medio para visualizarlo era el asistente para imprimir de IE8.
El archivo existia pero no era visible, por ningun medio, en el directorio en cuestion.
La solucion:
El modo protegido crea un directorio virtual ubicado en:
C:\Users\Usuario\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\
Con lo que, los archivos que se pretendan guardar en c:\users\Usuario\Desktop
Se guardan en primera instancia en :
......\Virtualized\C\Users\Usuario\Desktop
Luego, si se considera segura la transaccion, se guardarán en la ruta "real"
En el caso de una impresión mediante tinypdf, el proceso se trunca y el resultado final es que no se guarda el documento.
Ahora ya sabemos en donde buscar documentos perdidos a causa del modo protegido.
Una solución para evitar contratiempos es desactivar el modo protegido, a nuestro riesgo.
Gracias a José Perez que me ayudó a encontrar el maldito archivo "fantasma".
martes, 17 de agosto de 2010
Cliente windows vista o seven no imprime bien en servidor de impresion linux
Le ocurrio a un amigo luego de instalar ubuntu 10.04 y compartir una impresora. Al instalar los clientes windows, aquellos cuyo sistema operativo es windows vista o seven, tienen problemas para imprimir.
Nos acordamos de que samba puede tener problemas con la encriptacion NTLMv2 y nos preguntabamos si la solucion no estaría en desactivar esa encriptacion en las negociaciones de sesiones smb.
La explicacion esta aqui: http://multingles.net/docs/jmt/wvsmb.html
En ese articulo se indica cómo modificar las politicas de windows para desactivar esa encriptacion. Incluso presenta una solucion sobre como modificar las politicas en aquellos sistemas que no cuentan con gpedit (ms siempre esta pensando en como joderle la vida al usuario starter).
Mi amigo fue un poco mas lejos y encontró cuales claves hay que modificar para cambiar esas politicas, y con eso resolver el problema. Al menos el problema de la encriptacion que describe el articulo de arriba.
Esas claves son:
HK_Local_Machine\System\CurrentControlSet\control\Lsa DWORD "LmCompatibilityLeveL" = 0
HK_Local_Machine\System\CurrentControlSet\control\Lsa\MSV1_0 Dword "NtLmMinClientxxxx" = 0x0000
"NtLmMinServer=" 0x0000
Luego de ese cambio, no solo se resolvio el problema de inicio de sesion, sino que, hasta el momento, los clientes windows vista y seven, imprimen sin problemas.
Gracias José!
Nos acordamos de que samba puede tener problemas con la encriptacion NTLMv2 y nos preguntabamos si la solucion no estaría en desactivar esa encriptacion en las negociaciones de sesiones smb.
La explicacion esta aqui: http://multingles.net/docs/jmt/wvsmb.html
En ese articulo se indica cómo modificar las politicas de windows para desactivar esa encriptacion. Incluso presenta una solucion sobre como modificar las politicas en aquellos sistemas que no cuentan con gpedit (ms siempre esta pensando en como joderle la vida al usuario starter).
Mi amigo fue un poco mas lejos y encontró cuales claves hay que modificar para cambiar esas politicas, y con eso resolver el problema. Al menos el problema de la encriptacion que describe el articulo de arriba.
Esas claves son:
HK_Local_Machine\System\CurrentControlSet\control\Lsa DWORD "LmCompatibilityLeveL" = 0
HK_Local_Machine\System\CurrentControlSet\control\Lsa\MSV1_0 Dword "NtLmMinClientxxxx" = 0x0000
"NtLmMinServer=" 0x0000
Luego de ese cambio, no solo se resolvio el problema de inicio de sesion, sino que, hasta el momento, los clientes windows vista y seven, imprimen sin problemas.
Gracias José!
domingo, 18 de julio de 2010
Ubuntu: Crear un acceso a un recurso remoto compartido por windows
El siguiente texto supone que el recurso remoto se encuentra en //192.168.1.102/compartido y dicho recurso no esta protegido por contraseña.
El modo de conectarse a un recurso remoto utilizando nautilus es:
En la barra de direccion escribir, por ejemplo: smb://192.168.1.102/compartido
Tambien puede utilizarse el asistente: archivo, conectar con el servidor, tipo de servicio, compartido por windows
Luego, si uno quiere automatizar el asunto podria crear una entrada en el archivo
/etc/fstab:
//192.168.1.102/compartido /media/compartido cifs users,rw,auto,guest 0 0
Luego de eso, como uno de los parametros de mount es "users", se le permite al usuario montar y desmontar el recurso.
A partir de aqui comienza una serie de problemas.
El primero con el que me encontré:
En algunos sistemas, el solo hecho de agregar esa linea en fstab hace que el recurso se vea en 'Equipo' (computer:///)
Entonces con solo hacer doble clic se monta, con clic derecho tambien se monta o se desmonta. En fin todo muy bonito.
En otros sistemas no encontré cómo hacer que el recurso aparezca en computer:///
La solucion que encontre fue simple: crear un lanzador con la siguiente linea de comando:
mount /media/compartido
Eso resolvio el primer problema.
Obviamente, todo esto fue pensando en el operador y en no tener que darle instrucciones cripticas para un operarador inexperto.
El segundo:
Con el recurso montado de ese modo las cosas parecen funcionar bien, hasta que uno se topa con este bug:
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1272315.html
Basicamente, cuando, desde nautilus, se intenta reemplazar un archivo con otro del mismo nombre, no nos deja. Tampoco se pueden modificar archivos con gedit ya que informa de un error impidiendo la modificacion.
Ese error en español es:
"Error inesperado: Archivo de texto en uso"
Y en ingles:
“Unexpected Error: Text file busy”
El error de nautilus al intentar reemplazar un archivo del mismo nombre es:
En español:
"Error al renombrar el archivo temporal: Archivo de texto en uso"
Y en ingles:
“Error while renaming temporary file: Text file busy”
Al parecer son los unicos dos problemas. Abrir archivos de open office no trae problemas, por ejemplo.
Sin embargo, el operador no sabe de bugs, ni le interesan, ni quiere lidiar con ellos.
La solucion que encontre fue la siguiente:
Todo es tan simple como crear un lanzador con la siguiente linea de comandos:
nautilus smb://192.168.1.102/compartido
El modo de conectarse a un recurso remoto utilizando nautilus es:
En la barra de direccion escribir, por ejemplo: smb://192.168.1.102/compartido
Tambien puede utilizarse el asistente: archivo, conectar con el servidor, tipo de servicio, compartido por windows
Luego, si uno quiere automatizar el asunto podria crear una entrada en el archivo
/etc/fstab:
//192.168.1.102/compartido /media/compartido cifs users,rw,auto,guest 0 0
Luego de eso, como uno de los parametros de mount es "users", se le permite al usuario montar y desmontar el recurso.
A partir de aqui comienza una serie de problemas.
El primero con el que me encontré:
En algunos sistemas, el solo hecho de agregar esa linea en fstab hace que el recurso se vea en 'Equipo' (computer:///)
Entonces con solo hacer doble clic se monta, con clic derecho tambien se monta o se desmonta. En fin todo muy bonito.
En otros sistemas no encontré cómo hacer que el recurso aparezca en computer:///
La solucion que encontre fue simple: crear un lanzador con la siguiente linea de comando:
mount /media/compartido
Eso resolvio el primer problema.
Obviamente, todo esto fue pensando en el operador y en no tener que darle instrucciones cripticas para un operarador inexperto.
El segundo:
Con el recurso montado de ese modo las cosas parecen funcionar bien, hasta que uno se topa con este bug:
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1272315.html
Basicamente, cuando, desde nautilus, se intenta reemplazar un archivo con otro del mismo nombre, no nos deja. Tampoco se pueden modificar archivos con gedit ya que informa de un error impidiendo la modificacion.
Ese error en español es:
"Error inesperado: Archivo de texto en uso"
Y en ingles:
“Unexpected Error: Text file busy”
El error de nautilus al intentar reemplazar un archivo del mismo nombre es:
En español:
"Error al renombrar el archivo temporal: Archivo de texto en uso"
Y en ingles:
“Error while renaming temporary file: Text file busy”
Al parecer son los unicos dos problemas. Abrir archivos de open office no trae problemas, por ejemplo.
Sin embargo, el operador no sabe de bugs, ni le interesan, ni quiere lidiar con ellos.
La solucion que encontre fue la siguiente:
Todo es tan simple como crear un lanzador con la siguiente linea de comandos:
nautilus smb://192.168.1.102/compartido
miércoles, 23 de junio de 2010
Cambiar el puerto de escucha del escritorio remoto de Windows
Sí, sí. Eso esta por todos lados. Incluso MS explica cómo hacerlo:
http://support.microsoft.com/kb/306759/es
El problema es qué hacer si luego de cambiar el puerto no funciona?
Lo que hay que hacer es desactivar el acceso remoto y luego volver a activarlo.
O mejor, desactivar el acceso remoto, aplicar el cambio en el registro y luego volver a activarlo. Los pillos de ms no aclaran eso y me hicieron perder un par de minutillos.
Para activar/desactivar: Panel de control, Sistema, Remoto.
Bueno, y por si llegaste hasta aqui con la esperanza de ver qué cambios hay que hacer y ni ganas de viajar hasta ms, aqui va:
http://support.microsoft.com/kb/306759/es
El problema es qué hacer si luego de cambiar el puerto no funciona?
Lo que hay que hacer es desactivar el acceso remoto y luego volver a activarlo.
O mejor, desactivar el acceso remoto, aplicar el cambio en el registro y luego volver a activarlo. Los pillos de ms no aclaran eso y me hicieron perder un par de minutillos.
Para activar/desactivar: Panel de control, Sistema, Remoto.
Bueno, y por si llegaste hasta aqui con la esperanza de ver qué cambios hay que hacer y ni ganas de viajar hasta ms, aqui va:
- Inicie el Editor del Registro (Regedt32.exe).
- Busque la siguiente clave del Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
- En el menú Edición, haga clic en Modificar, Decimal, escriba el nuevo número de puerto y, después, haga clic en Aceptar.
- Salga del Editor del Registro.
viernes, 7 de mayo de 2010
Error al desinstalar el dispositivo. Puede que sea necesario para iniciar el equipo
A cuantos les paso que quieren desinstalar un dispositivo y les manda ese mensaje casi sin sentido.
Para los ansiosos, antes de que me odien mientras leen mi relato, abajo, en color rojo esta la solucion, je!
Claro, el dispositivo esta en conflicto, no funciona, no sirve, incluso se puede deshabilitar, pero windows no deja desinstalarlo.
El problema es que ese dispositivo en conflicto hace que algo no este funcionando.
Lo mas desconcertante es que uno navega y navega por la red sin obtener una sola respuesta certera. Es comun leer en los foros la palabra resuelto o solved. Ja! y como lo resuelven? formating...andaaaaaaaaaaaaaa!!!!!
Voy a contar como lo resolvi yo en el caso particualar de varios dispositivos de red virtuales imposibles de quitar.
Eso provocaba el siguiente comportamiento:
Si la configuracion de la red estaba en automatico, todo funcionaba bien, pero si le asignaba una direccion ip manualmente, dejaba de funcionar luego de reiniciar.
Habia que ejecutar
netsh int ip reset resetlog.txt
y luego reinciar. Ahi tomaba una ip del DHCP y funcionaba bien. Si en ese momento le asignaba una ip, seguia funcionando bien, pero luego de reiniciar, la red estaba dañada. Al ejecutar, por ejemplo:
ipconfig
no mostraba nada.
LA SOLUCION (para el caso de un dispositivo de red)
En la configuracion de la red bastó quitar el servicio "programador de paquetes QOS" para que se resolviera todo. No solamente se reparo la red, sino que desaparecieron los dispositivos zombies.
Quitar ese servicio resolvio mi problema. En otros casos habra que quitar otro servicio o protocolo. El unico que sí debe quedar siempre es tcp/ip, el cual puede repararse con el comando netsh indicado mas arriba.
Si es necesario quitar el servicio "Compartir archivos e impresoras" o "Clientes para redes", pero es necesario para el funcionamiento del equipo, no dudo que una vez resuelto el problema, al volver a instalarlo, todo quedara bien.
Si estas leyendo esto y tu problema no es la placa de red, no desesperes. Lo que yo haria, tratandose del sonido, es entrar al panel de control, Dispositivos de sonido, y comenzaria a intentar quitar configuraciones extra. Cosas como "usar solo dispositivos predeterminados", etc.
Para los ansiosos, antes de que me odien mientras leen mi relato, abajo, en color rojo esta la solucion, je!
Claro, el dispositivo esta en conflicto, no funciona, no sirve, incluso se puede deshabilitar, pero windows no deja desinstalarlo.
El problema es que ese dispositivo en conflicto hace que algo no este funcionando.
Lo mas desconcertante es que uno navega y navega por la red sin obtener una sola respuesta certera. Es comun leer en los foros la palabra resuelto o solved. Ja! y como lo resuelven? formating...andaaaaaaaaaaaaaa!!!!!
Voy a contar como lo resolvi yo en el caso particualar de varios dispositivos de red virtuales imposibles de quitar.
Eso provocaba el siguiente comportamiento:
Si la configuracion de la red estaba en automatico, todo funcionaba bien, pero si le asignaba una direccion ip manualmente, dejaba de funcionar luego de reiniciar.
Habia que ejecutar
netsh int ip reset resetlog.txt
y luego reinciar. Ahi tomaba una ip del DHCP y funcionaba bien. Si en ese momento le asignaba una ip, seguia funcionando bien, pero luego de reiniciar, la red estaba dañada. Al ejecutar, por ejemplo:
ipconfig
no mostraba nada.
LA SOLUCION (para el caso de un dispositivo de red)
En la configuracion de la red bastó quitar el servicio "programador de paquetes QOS" para que se resolviera todo. No solamente se reparo la red, sino que desaparecieron los dispositivos zombies.
Quitar ese servicio resolvio mi problema. En otros casos habra que quitar otro servicio o protocolo. El unico que sí debe quedar siempre es tcp/ip, el cual puede repararse con el comando netsh indicado mas arriba.
Si es necesario quitar el servicio "Compartir archivos e impresoras" o "Clientes para redes", pero es necesario para el funcionamiento del equipo, no dudo que una vez resuelto el problema, al volver a instalarlo, todo quedara bien.
Si estas leyendo esto y tu problema no es la placa de red, no desesperes. Lo que yo haria, tratandose del sonido, es entrar al panel de control, Dispositivos de sonido, y comenzaria a intentar quitar configuraciones extra. Cosas como "usar solo dispositivos predeterminados", etc.
Suscribirse a:
Entradas (Atom)