Una forma es arrancar Wireshark en un equipo conectado unicamente al dispositivo. Iniciar la captura y encender el dispositivo.
Wireshark comenzará a mostrar paquetes. Solo es cuestion de un poco de intuicion para descubrir la ip.
Por ejemplo:
En wireshark aparece who has 192.168.1.1 ask 192.168.1.252. De ahi se
desprende que el dispositivo tiene la ip 192.168.1.252
En el caso especial de que el dispositivo fuera un router configurado
como gateway, no es necesario Wireshark, suponiendo que el dispositivo tenga activado DHCP. En ese caso la solucion es
bastante simple: configurar la red de la pc en automatico y esperar
que el servidor DHCP del router asigne una ip.
sábado, 21 de septiembre de 2013
domingo, 5 de agosto de 2012
Otro caso de "brujería"
Creo que debería abrir un blog especial de brujeria porque a raiz de mi ultima entrada comencé a acordarme de varios casos "sin solución"
Escenario:
Una empresa con cuatro sucursales.
En cada sucursal hay una impresora fiscal marca Hasar y un programa escrito en Visual Basic corriendo bajo windows xp en un caso y vista en el resto. Ese programa se conecta con la impresora fiscal para emitir las facturas.
El problema:
En dos de las sucursales el texto correspondiente a la razón social sale truncado.
La providencia quiso que se pueda descartar el sistema operativo pues la version y service pack de aquel en el que sí funciona (windows vista) es la misma que en donde funciona mal. Ademas tampoco funciona en un terminal con windows xp.
El programador le atribuye el problema a la impresora.
Los de la impresora, a su vez, le atribuyen el problema al programa.
Las pruebas:
Los de la impresora hicieron "enroque" de impresoras y verificaron que el corte de texto se produce exclusivamente en la sucursal, por lo tanto no es problema de la impresora.
El programador dice que la version del programa es exactamente la misma en todas las sucursales. Por lo tanto tampoco es el programa.
Me contratan para que encuentre la causa del problema.
Mis pruebas:
Los sospechosos son: el puerto serie y el driver.
Me enfoco en el driver de la impresora fiscal.
Se llama fiscal.ocx.
Tomo nota de la versión del ocx en una sucursal y la comparo con el homonimo de la otra sucursal. Son la misma versión: 1.0.0.1
La solución:
Sospechando de la veracidad del informe de versión, hago una copia del fiscal.ocx de la sucursal en la que sí funciona.
Me voy a una sucursal con problemas y comparo ambos archivos con el comando fc. A pesar de que MS informa que ambos tienen la misma versión, son distintos. Lo reemplazo. Problema resuelto.
Conclusión:
La brujería no existe. No crean en todo lo que dice MS. No es necesario tener grandes conocimientos para resolver problemas complejos.
Escenario:
Una empresa con cuatro sucursales.
En cada sucursal hay una impresora fiscal marca Hasar y un programa escrito en Visual Basic corriendo bajo windows xp en un caso y vista en el resto. Ese programa se conecta con la impresora fiscal para emitir las facturas.
El problema:
En dos de las sucursales el texto correspondiente a la razón social sale truncado.
La providencia quiso que se pueda descartar el sistema operativo pues la version y service pack de aquel en el que sí funciona (windows vista) es la misma que en donde funciona mal. Ademas tampoco funciona en un terminal con windows xp.
El programador le atribuye el problema a la impresora.
Los de la impresora, a su vez, le atribuyen el problema al programa.
Las pruebas:
Los de la impresora hicieron "enroque" de impresoras y verificaron que el corte de texto se produce exclusivamente en la sucursal, por lo tanto no es problema de la impresora.
El programador dice que la version del programa es exactamente la misma en todas las sucursales. Por lo tanto tampoco es el programa.
Me contratan para que encuentre la causa del problema.
Mis pruebas:
Los sospechosos son: el puerto serie y el driver.
Me enfoco en el driver de la impresora fiscal.
Se llama fiscal.ocx.
Tomo nota de la versión del ocx en una sucursal y la comparo con el homonimo de la otra sucursal. Son la misma versión: 1.0.0.1
La solución:
Sospechando de la veracidad del informe de versión, hago una copia del fiscal.ocx de la sucursal en la que sí funciona.
Me voy a una sucursal con problemas y comparo ambos archivos con el comando fc. A pesar de que MS informa que ambos tienen la misma versión, son distintos. Lo reemplazo. Problema resuelto.
Conclusión:
La brujería no existe. No crean en todo lo que dice MS. No es necesario tener grandes conocimientos para resolver problemas complejos.
La brujeria no existe en computación
El escenario es el siguiente:
Una red de siete terminales, todos con windows xp, más un servidor windows 2000, más un NAS-235 Airlive.
Los terminales utilizan sin problemas archivos word, excel, etc., almacenados en el nas, del mismo modo que los almacenados en el servidor windows.
Los terminales ejecutan un programa compilado en Visual Basic que accede a una base de datos access.
El problema:
Si la base de datos access se aloja en el nas, el programa conecta algunas veces y otras no. Sin embargo conecta sin problemas cuando la base de datos reside en el servidor Windows.
Los antecedentes:
El administrador de la red informa que el problema ocurre en todas las pc de la red.
De esto hace ya mas de un año. El tecnico le pateó el problema al programador y se cruzó de brazos.
Entonces el programador me contrata para resolver el problema.
Las pruebas:
Hago las pruebas en cuatro pc de la red y efectivamente el comportamiento es como se describe en "el problema"
Instalo el nas en mi propia red y funciona perfecto.
Pienso: no habrá sido cuestion de reiniciar el nas????
Lo llevo nuevamente al lugar y sigue con el mismo problema.
Para aislar el problema de la red, conecto el nas directamente a una pc y el problema se repite. Ergo: la red no es
Pienso será la version del programa? Bueno eso es fácil: me llevo el ejecutable junto con el nas de nuevo para probar en mi red: funciona perfecto.
La conclusión es clara: no hay brujería, todas las pc de la red tienen un problema.
Yo había probado con cuatro, pero serían todas?
Comienzo a probar de a una. La prueba es muy simple: solo redireccionar el programa para que lea una base de datos de prueba alojada en el nas. Son cinco minutos por maquina.
Mientras hago las pruebas tomo nota del sistema operativo. Todas tienen Windows XP sp2.
A partir de ahi comienzo a sospechar del service pack. Sigo haciendo pruebas y ya hasta me animo a predecir el resultado segun el SP. En las pruebas que habia hecho en mi red era SP3 y si no encontraba un sp3 en esa otra red, no lograría hacer funcionar el programa. Esa era mi predicción.
Llego a la quinta pc y leo antes el SP: tiene sp3!! y pienso aca va a funcionar...Efectivamente, funcionó.
Conclusión:
No existe la brujería. El nas andaba perfecto, el programa tambien.
No hacen falta grandes conocimientos para resolver muchos de los problemas, solo intuición y ganas.
Alguien con grandes (o al menos medianos) conocimientos, tal vez hubiese instalado un analizador de protocolo para examinar cada paquete transmitido y llegar, luego de tal vez horas de análisis, que el problema estaba en el service pack por la falta de un parche.
La verdad, sería muy interesante analizar qué parche de todos los que contiene el sp3 es el que resuelve el problema, pero a mí me bastó encontrar la solución.
El tecnico se comprometió a actualizar el SO en todas las maquinas y problema resuelto.
Una red de siete terminales, todos con windows xp, más un servidor windows 2000, más un NAS-235 Airlive.
Los terminales utilizan sin problemas archivos word, excel, etc., almacenados en el nas, del mismo modo que los almacenados en el servidor windows.
Los terminales ejecutan un programa compilado en Visual Basic que accede a una base de datos access.
El problema:
Si la base de datos access se aloja en el nas, el programa conecta algunas veces y otras no. Sin embargo conecta sin problemas cuando la base de datos reside en el servidor Windows.
Los antecedentes:
El administrador de la red informa que el problema ocurre en todas las pc de la red.
De esto hace ya mas de un año. El tecnico le pateó el problema al programador y se cruzó de brazos.
Entonces el programador me contrata para resolver el problema.
Las pruebas:
Hago las pruebas en cuatro pc de la red y efectivamente el comportamiento es como se describe en "el problema"
Instalo el nas en mi propia red y funciona perfecto.
Pienso: no habrá sido cuestion de reiniciar el nas????
Lo llevo nuevamente al lugar y sigue con el mismo problema.
Para aislar el problema de la red, conecto el nas directamente a una pc y el problema se repite. Ergo: la red no es
Pienso será la version del programa? Bueno eso es fácil: me llevo el ejecutable junto con el nas de nuevo para probar en mi red: funciona perfecto.
La conclusión es clara: no hay brujería, todas las pc de la red tienen un problema.
Yo había probado con cuatro, pero serían todas?
Comienzo a probar de a una. La prueba es muy simple: solo redireccionar el programa para que lea una base de datos de prueba alojada en el nas. Son cinco minutos por maquina.
Mientras hago las pruebas tomo nota del sistema operativo. Todas tienen Windows XP sp2.
A partir de ahi comienzo a sospechar del service pack. Sigo haciendo pruebas y ya hasta me animo a predecir el resultado segun el SP. En las pruebas que habia hecho en mi red era SP3 y si no encontraba un sp3 en esa otra red, no lograría hacer funcionar el programa. Esa era mi predicción.
Llego a la quinta pc y leo antes el SP: tiene sp3!! y pienso aca va a funcionar...Efectivamente, funcionó.
Conclusión:
No existe la brujería. El nas andaba perfecto, el programa tambien.
No hacen falta grandes conocimientos para resolver muchos de los problemas, solo intuición y ganas.
Alguien con grandes (o al menos medianos) conocimientos, tal vez hubiese instalado un analizador de protocolo para examinar cada paquete transmitido y llegar, luego de tal vez horas de análisis, que el problema estaba en el service pack por la falta de un parche.
La verdad, sería muy interesante analizar qué parche de todos los que contiene el sp3 es el que resuelve el problema, pero a mí me bastó encontrar la solución.
El tecnico se comprometió a actualizar el SO en todas las maquinas y problema resuelto.
domingo, 11 de septiembre de 2011
Compartir carpetas en discos extraibles
Lo que ocurre normalmente es lo siguiente:
Si el disco extraible tiene formato ntfs, windows recuerda siempre la configuracion de las carpetas compartidas.
Si el disco extraible tiene formato fat32, windows se olvida de los recursos compartidos luego de un reinicio.
O sea que, en los casos en que el disco es extraido periodicamente, es conveniente que el formato sea ntfs.
Sin embargo ocurre un segundo problema y es el cambio de letra. Si windows cambiara la letra del dispositivo, entonces el recurso deja de estar compartido.
Una solucion a ambos problemas y que sirve para cualquiera de los dos sistemas (ntfs, fat32) es el siguiente script o archivo batch (extension bat):
El que sigue es un ejemplo para el caso de un pendrive cuyo nombre de volumen (1) es Sistemas y la carpeta a compartir se llama Ventas y está en el raiz del disco extraible, por ejemplo: C:\Ventas
echo ESTE SCRIPT REQUIERE QUE EXISTA UN DIRECTORIO C:\Compartir !!!!!!
cd c:\compartir
echo list volume | diskpart | find /i "Sistemas" > prueba.txt
for /f "tokens=3" %%i in (prueba.txt) do net share Ventas=%%i:\Ventas /unlimited
Podria utilizarse la carpeta de sistema Temp, en lugar c:\Compartir y de ese modo se evita tener que crear dicha carpeta. Cuestion de gustos.
La necesidad del comando cd c:\compartir ocurre porque no logré que el comando "for" interprete c:\compartir\prueba.txt. Y como al ejecutar el script dentro del directorio puede usarse una referencia relativa (y no absoluta) al archivo prueba.txt, ya no se presenta el problema (2)
El parametro tokens=3 hace que "for" lea la tercer palaba de la primera linea del archivo prueba.txt. Y como la cantidad de lineas que contiene el archivo es una sola, el for se ejecuta una sola vez, obteniendo asi la letra de la unidad extraible (3)
El parametro /i permite olvidarse de si el nombre del volumen esta en mayusculas o minusculas.
Notas:
(1) para cambiar el nombre de volumen de un disco hay que hacer clic con botón derecho sobre el disco (en Mi Pc), luego propiedades y luego en la pestaña general, en el cuadro de texto que aparece arriba del todo (ver el cursor) se puede escribir el nombre de volumen.
(2) Es muy probable que un parámetro resuelva este comportamiento. La verdad es que hice un par de pruebas con parametros y simbolos, pero, antes que lidiar con las mañas de los comandos, es mas simple el corte por lo sano, siempre que funcione :-D
(3) Eso es asi siempre y cuando no haya mas de un dispositivo con el mismo nombre de volumen. Es esperable el buen criterio del tecnico al poner nombres de volumen a las unidades extraibles.
Si el disco extraible tiene formato ntfs, windows recuerda siempre la configuracion de las carpetas compartidas.
Si el disco extraible tiene formato fat32, windows se olvida de los recursos compartidos luego de un reinicio.
O sea que, en los casos en que el disco es extraido periodicamente, es conveniente que el formato sea ntfs.
Sin embargo ocurre un segundo problema y es el cambio de letra. Si windows cambiara la letra del dispositivo, entonces el recurso deja de estar compartido.
Una solucion a ambos problemas y que sirve para cualquiera de los dos sistemas (ntfs, fat32) es el siguiente script o archivo batch (extension bat):
El que sigue es un ejemplo para el caso de un pendrive cuyo nombre de volumen (1) es Sistemas y la carpeta a compartir se llama Ventas y está en el raiz del disco extraible, por ejemplo: C:\Ventas
echo ESTE SCRIPT REQUIERE QUE EXISTA UN DIRECTORIO C:\Compartir !!!!!!
cd c:\compartir
echo list volume | diskpart | find /i "Sistemas" > prueba.txt
for /f "tokens=3" %%i in (prueba.txt) do net share Ventas=%%i:\Ventas /unlimited
Podria utilizarse la carpeta de sistema Temp, en lugar c:\Compartir y de ese modo se evita tener que crear dicha carpeta. Cuestion de gustos.
La necesidad del comando cd c:\compartir ocurre porque no logré que el comando "for" interprete c:\compartir\prueba.txt. Y como al ejecutar el script dentro del directorio puede usarse una referencia relativa (y no absoluta) al archivo prueba.txt, ya no se presenta el problema (2)
El parametro tokens=3 hace que "for" lea la tercer palaba de la primera linea del archivo prueba.txt. Y como la cantidad de lineas que contiene el archivo es una sola, el for se ejecuta una sola vez, obteniendo asi la letra de la unidad extraible (3)
El parametro /i permite olvidarse de si el nombre del volumen esta en mayusculas o minusculas.
Notas:
(1) para cambiar el nombre de volumen de un disco hay que hacer clic con botón derecho sobre el disco (en Mi Pc), luego propiedades y luego en la pestaña general, en el cuadro de texto que aparece arriba del todo (ver el cursor) se puede escribir el nombre de volumen.
(2) Es muy probable que un parámetro resuelva este comportamiento. La verdad es que hice un par de pruebas con parametros y simbolos, pero, antes que lidiar con las mañas de los comandos, es mas simple el corte por lo sano, siempre que funcione :-D
(3) Eso es asi siempre y cuando no haya mas de un dispositivo con el mismo nombre de volumen. Es esperable el buen criterio del tecnico al poner nombres de volumen a las unidades extraibles.
sábado, 16 de abril de 2011
Cambiar directorio de almacenamiento de correo electronico a un pendrive o disco remoto
En Outlook:
Primero obtener la ruta del arhivo pst:
Herramientas, Opciones, Configuracion de correo, Archivos de datos.
Suele estar en C:\Users\USUARIO\AppData\Local\Microsoft\Outlook\Outlook1.pst
Mover Outlook1.pst a un directorio distinto, que tambien puede ser remoto. Iniciar Outlook. Al no encontrar Outlook1.pst, pues fue movido, pide la nueva ruta. Se la indica y listo. Ya queda funcionando en la nueva ruta. Lo bueno del programa es que no hace como Outlook Express que, al no encontrar la ruta, automaticamente se configura en la ruta por defecto.
En Outlook Express:
Desde las opciones de configuracion no permite indicar un directorio de almacenamiento remoto o un pendrive.
Para forzarlo hay que modificar el registro:
HKEY_CURRENT_USER\Identities\{Identidad}\Software \Microsoft\Outlook
express\5.0" y modificar la clave "Store root"
En esa clave se indica la ruta local, remota, pendrive, etc. Simplemente se hace doble clic en dicha clave y se modifica la ruta actual por la deseada.
Luego se puede copiar el contenido (correos) desde la ruta original en la nueva ruta.
Si la ruta no esta disponible momento de iniciar el programa, este se configura en los valores por defecto y queda asi aunque luego se restaure la ruta.
Por eso conviene exportar la clave anterior para incorporarla cada vez que ocurra eso. Tambien se puede armar un script para iniciar el programa que incorpore automaticamente la entrada del registro.
Si la ruta no esta disponible momento de iniciar el programa, este se configura en los valores por defecto y queda asi aunque luego se restaure la ruta.
Por eso conviene exportar la clave anterior para incorporarla cada vez que ocurra eso. Tambien se puede armar un script para iniciar el programa que incorpore automaticamente la entrada del registro.
En Mozilla Thunderbird:
Herramientas, Configuracion de las cuentas, Configuracion del servidor, Directorio local:
Primero tomar nota de la ruta actual
Modificar la ruta, que puede ser local o remota.
Cerrar el programa y mover el contenido del directorio original al nuevo directorio.
Windows Mail:
No encontré como hacerlo. Creo que tiene que ver el hecho de que este programa guarda archivos del tipo eml, los cuales tienen propiedades especiales ntfs que no pueden guardarse en sistemas fat32, por ejemplo.
domingo, 12 de diciembre de 2010
Samba: compartir un sistema ntfs en Ubuntu 10.10
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.
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.
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".
Suscribirse a:
Entradas (Atom)