[QUICKFIX] Ubuntu no encuentra el CDROM

Ahhhh el año 2015… tenemos gente con dinero que come pedacitos de oro para que su caca sea, bueno, dorada, encontramos – por quincuagésima vez – agua en Marte, tenemos un doble anillo de chiquicientos miles de metros enterrado en algún lado del planeta que no me acuerdo el nombre que acelera partículas subatómicas a la velocidad de la luz y las colisiona entre ellas para simular las condiciones en las cuales se generó el universo, y por supuesto… nuestro gran ídolo Arjona sigue vivito y coleando.

Oh… What a great time to be alive.

Excepto por el instalador de Ubuntu Server 14.04.2 LTS, por supuesto. Parece que Canonical, a pesar de todo, todavía no puede desarrollar un instalador que funcione (mucho menos que sea intuitivo).

Parece ser que el señor espera que instalemos mediante CD – quién carajo usa CDs todavía? – y se olvida completamente de que podríamos, quizás, estar instalando desde un pendrive USB. Y repito: estamos en el 2015 y 14.04 fue lanzando en el 2014….

La solución, al menos en mi caso, fue simple, pero ustedes pueden tener una versión distinta del error y las soluciones que vi por ahi son todas una mierda; ergo, ete aquí mi post (además, siempre que vuelvo a tener este problema me olvido de cómo solucionarlo y tengo que volver a googlear y me da paja).

(El pendrive fue quemado con Rufus, puede llegar a influír en algo)

Cuando les de el error, apretan CTRL + ALT + F2 y dan enter para generar un shell. Acá tienen que desmontar el pendrive (que fue montado en /media por el instalador) y volverlo a montar en /cdrom. O sea:

umount /media
mount /dev/sdb1 /cdrom

Puede que el device de ustedes sea otro sdX, por lo que escribiendo “mount” va a encontrar una lista de cositas montadas, fíjense cuál es el device montado en /media y usen ese.

Ahora simplemente se vuelven a la consola de instalación con CTRL + ALT + F1 y le dicen que vuelva a buscar el dispositivo. Listo, con eso basta.

Si tienen consultas, pueden dejarlas en los comentarios.

Anuncios

Montar carpeta compartida entre dos o más Linux con SSHFS

Bueno, estuve intentando hacer andar una especie de “bolsa” con Samba, pero no hubo suerte con el asunto de permisos, por lo que me tuve que volcar por otra solución y esa solución terminó siendo SSHFS ( https://help.ubuntu.com/community/SSHFS ).

Para esto, vamos a concretar 2 partes, la del servidor primero y la del cliente después.

  • En el servidor:

Tengo un pfSense (FreeBSD), al que primero antes que nada hay que habilitarle la posibilidad de entrar por SSH, esto se hace entrando a la consola por el navegador y yendo a System -> Advanced y en el sub de Secure Shell, le damos “Enable Secure Shell”. Apretamos Save y a los pocos segundos el servicio ya está funcionando.

También, si alguno de ustedes está con otro OS que no sea pfSense, quizás quieran leer esto porque hace falta editar sshd_config. Fijense acá: http://www.strugglingcoder.info/index.php/sshfs-on-freebsd/

Para probarlo, ingresamos al servidor por ssh, onda: ssh [tuusuario]@192.168.1.1. Adentro les va a presentar el menu de pfSense para las tty, y elijen la opción 8 que es Shell.
Lo que vamos a hacer es agregar un usuario, agregar una carpeta en el /, y cambiarle el grupo para que tenga permisos de escritura sin necesidad de que sea root. Hacemos:

pw useradd usuario -G admins
passwd usuario

Esto crea el user usuario y lo mete en el grupo admins, y con el segundo comando le seteamos una contraseña. Después de esto hacemos esto:

mkdir /bolsa
chown -R usuario:admins /bolsa

Con esto creamos una carpeta en el raíz, y le cambiamos el owner a usuario y el grupo a admins para que el usuario que creamos antes pueda hacer lo que quiera adentro. Por default estas carpetas se crean con el usuario root y el grupo wheel y si no hacemos esto después no nos vamos a poder conectar. Por si las moscas, hacemos esto:

chmod 775 /bolsa

Como para asegurarnos de que el grupo tenga todos los permisos en la carpeta.

Estamos listos en el servidor, pasemos al cliente:

  • En el cliente

Yo tengo todo basado en Debian acá asique cada uno sabrá usar su gestor de paquetes. Primero instalamos lo necesario para poder conectarnos:

sudo apt-get install fuse sshfs

Ahora tenemos que agregar nuestro usuario al grupo fuse para que pueda montar y ver filesystems basados en FUSE (en el que se basa justamente SSHFS). Sin esto no vas a poder ver la carpeta montada a menos que seas root, la vas a ver como d????????? en el nombre

sudo gpasswd -a usuario fuse

(cambien [usuario] por el usuario con el que están logueados)

Estamos listos para probar:

sshfs usuario@192.168.1.1:/bolsa /mnt

Esto lo que hace es conectarse como lo harían por ssh con el user usuario que definimos ni bien arrancamos, al servidor en 192.168.1.1, a la carpeta /bolsa que creamos, y lo va a montar automáticamente en /mnt

Listo, no tienen que hacer más nada, ya tienen la carpeta montada y funcionando perfectamente.

  • Consideraciones

Al principio me pasaba que el comando sshfs no conectaba, se quedaba tildado y tenía que cancelarlo. Esto era porque el usuario con el que me estaba conectando al ssh no tenía permisos a la carpeta que había creado.

Si les pasa que se tilda, o les da error, o lo que carajo sea, cuando intenten conectarse de nuevo los va a putear en arameo por una cuestión del FS, algo así como “fuse: bad mount point `/bolsa/’: transport is not connected“. Esto es porque se colgó, hay que liberar el punto de montaje con fusermount -u -z /bolsa

Para desmontar el punto de montaje usan fusermount -u /mnt

Leí por ahí que suele suceder que el ssh se desconecta por un parámetro de la configuración del mismo. En el cliente tienen que editar el archivo /etc/ssh/ssh_config y agregar esto al final:

ServerAliveInterval 60

Esto va a mandar cada 60 segundos un código no-op para que no los desconecte.

  • Addendum: hacer que SSHFS monte la unidad automáticamente

Para esto vamos a tener que repasar un par de asuntos. Primero, tenemos que asegurarnos de que el usuario al que nos estamos conectando en el servidor tenga shell, esto lo vemos haciendo cat /etc/passwd y mirando si en la línea que corresponde a usuario dice /sbin/nologin o similar. Para solucionar esto hacemos: chsh -s /bin/sh usuario. Por supuesto, pueden usar otro shell ( /bin/bash, por ejemplo)

Tenemos que poder hacer ssh usuario@192.168.1.1 sin problemas. Lo que vamos a hacer ahora es configurar al servidor para que acepte la clave pública de nuestro cliente y así no sea necesario poner la contraseña. NOTA: intenté por todos los medios buscar una alternativa a usar keys ssh, pero no hubo forma. Ni hardcodeando el password, ni utilizando la opción password_stdin de sshfs, ni utilizando otros programas. La única forma fiable es usar keys ssh.

En el cliente hacemos:

ssh-keygen -t rsa
[le dan enter a todo lo que sigue]
ssh usuario@192.168.1.1 mkdir -p .ssh
cat .ssh/id_rsa.pub | ssh usuario@192.168.1.1 ‘cat >> .ssh/authorized_keys’

Ahora deberían poder hacer ssh al servidor tranquilamente sin que les pida contraseña.

Ahora lo que vamos a hacer, de nuevo en el cliente, es editar el /etc/fstab

sudo nano /etc/fstab

Y al final de todo agregamos esto:

sshfs#usuario@192.168.1.1:/bolsa   /bolsa  fuse    idmap=user,uid=1000,gid=1000,allow_other,_netdev,IdentityFile=/home/usuario/.ssh/id_rsa    0   0

He probado con varias opciones, las tuyas pueden variar, pero básicamente estas me han funcionado. Voy a ir probando cuales mantienen funcionalidad y cuales no y si puedo actualizo el post.

Si quieren probar si esto quedó andando, reinicien el equipo y van a ver que después de loguearse con su usuario la carpeta va a estar conectada. Yo lo que hice después fue hacer simplemente un acceso directo en el escritorio para que me quede a mano.

ln -s /mnt /home/usuario/Escritorio/bolsa

Listo, les debería quedar andando todo esto sin ningún problema. Cualquier cosa, me consultan en los comentarios o agarran google y lo hacen de goma, como yo, que hace 2 días que vengo renegando con esto para hacerlo andar y escribir 3 boludeces. No se dan una idea del MAR de pestañas que tengo abiertas jaja

KVM no bootea CentOS 5.6 con drivers VirtIO

Amo internet, amo la gente que escribe en los foros, amo la gente que postea soluciones, los amo a todos muchachos, a TODOSAAHsgadghjajadfajsd

Estoy migrando un CentOS 5.6 de VirtualBox a KVM-qemu, y resulta que el muy puto no booteaba, largando un mensaje similar al siguiente:

La clave acá está en que decía “Trying to resume from /dev/sda2” y me puteaba en arameo cuando intentaba montar el filesystem; claramente un problema relacionado al disco. Probando boludeces terminé intentando iniciar con el driver IDE (que generalmente anda) y, como era de esperarse, booteó.

Anduve escarbando un rato y me encontré con este post:

https://www.centos.org/forums/viewtopic.php?t=28942

Que apunta a este post:

https://www.centos.org/forums/viewtopic.php?t=14647

Y todo tuvo sentido: faltan cargar los módulos de virtio en el kernel. Entonces lo que hay que hacer es iniciar el CentOS con los drivers IDE, o en tu VM anterior, o sea lo que sea que te permita entrar a tu shell y escribir lo siguiente:

mkinitrd –with virtio –with virtio_ring –with virtio_blk –with virtio_net –with virtio_pci -f /boot/initrd-$(uname -r).img $(uname -r)

Esto incluye los módulos necesarios. Hacele un shutdown, cambiá a los drivers VirtIO en el virt-manager y listo el pollo! CentOS arriba!

Soy feliz 😀

EDIT: novedades! La performance apestaba. por lo que tuve que seguir investigando y di con esto:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/ch10s04.html

Hay que editar /etc/rc.d/rc.sysinit y agregar unos asuntos, hay que asegurarse de que la intefaz de red tenga desactivados GSO y TSO (que ni idea qué cuernos son, pero ahora me fijo) y cambiar /etc/fstab con /dev/vdX (porque los discos virtuales no utilizan el nombre sdX)

Otra lectura que encontré es esta:

http://wiki.libvirt.org/page/Virtio

WORKAROUND: Servicio de Spooler de Windows 7 no se inicia automáticamente

Hace unos días me cayó una notebook con el servicio de Cola de Impresión (Spooler) de Windows 7 detenido. El servicio inicia bien manualmente, pero cuando se lo pasa a Modo de Inicio Automático y reiniciás, siempre vuelve al estado “Manual”, obligándote así a volver a iniciarlo de modo manual.

Si googleás, en un toque te vas a dar cuenta de que es un problema bastante común. Probé todos los fixes que había, nada funcionó. Algunos de los fixes son:

http://www.sysprobs.com/print-spooler-stopping-automatically-fix
https://social.technet.microsoft.com/Forums/windows/en-US/fd7f46d3-baa1-4a38-9ad3-dec5426d9297/print-spooler-keeps-stopping-on-windows-7
[el segundo link tiene varias sugerencias, entre ellas chequear las dependencias del servicio de Cola de Impresión, y cambiar el Ownership de spoolsv.exe]

Pero nada de esto funcionó. Me volvió loco durante un par de días hasta que encontré una forma de darle la vuelta.

Básicamente lo que hay que hacer es lograr ejecutar un .bat con permisos administrativos en el inicio de sesión. El .bat es muy simple, sólo corre el siguiente comando: net start spooler

El quilombo viene por el lado de hacer correr un .bat con derechos Administrativos. Así hay que hacer:

– Primero, te creás por ahí en alguna carpeta (yo lo hice en el directorio raíz) un archivo de texto (.txt) que diga “net start spooler” [sin las comillas, menso]
– Lo renombrás de .txt a .bat
– Probá de ejecutarlo como Administrador (clic derecho -> ejecutar como Administrador) o abriendo una ventana de cmd con derechos Administrativos (inicio -> escribir: cmd -> clic derecho -> ejecutar como Administrador). Debería iniciar el servicio de Cola de Impresión.
– Ahora abrimos el Programador de Tareas, y creamos una Crear Tarea [ejemplo: http://b2b.cbsimg.net/gallery/186932-500-413.png ]
– En la ventana de Crear Tarea, en la pestaña General seteás el nombre, una descripción si te pinta, y asegurate de que esté tildado “Ejecutar con privilegios más altos”
– Ahora movete a la pestaña Desencadenadores. Hacé clic en Nuevo, y donde dice “Iniciar la tarea:” ponele Al Iniciar la sesión. Podés seleccionar Cualquier Usuario o el Usuario específico que querés que la inicie, yo prefiero el primero. El resto de las opciones van a criterio personal. Hacé clic en Aceptar.
– De nuevo en la ventana de Crear Tarea, andá a la pestaña Acciones, hacé clic en Nueva… y en “Accion:” ponele Iniciar un programa. Ahora con el botón Examinar buscás el .bat que habías creado en el primer paso y le das Aceptar.

Listo. Aceptá todo, guardá y reiniciá. Al concederle “privilegios más altos”, ni siquiera el UAC de Windows va a detener la tarea o siquiera te va a preguntar.

Si te sirvió mi workaround, dejate un comentario, ya que mi alma, mi ego y mis ganas de seguir publicando estas pelotudeces que ustedes deberían encontrar por sus propios medios – como yo – se alimentan de un simple “eh wacho le kbio al puto del w7 ahora puedo imprimir los gifs de minas en bolas”

Chau

Configurar una carpeta compartida y pública en pfSense

Buenas. ¿Ya patchearon Shellshock? ¿No? Bueno yo tampoco pero el fin de semana me pongo…

Las guías que hago las vengo compartiendo a medida que hago algo que necesito, y que sé que a lo mejor le puede llegar a servir a alguien en el futuro, pero más que nada las reproduzco acá para poder tener una referencia personal. Dicen que se aprende dos veces: primero leyendo y después enseñando. Hoy toca agregarle al router pfSense que vengo implementando una carpeta compartida para que los usuarios puedan pasar archivos de un lado al otro; la famosa “bolsa” que tanto usamos por estos lugares.

Lo primero que hay que hacer es entrar al shell del pfSense, ya sea directamente conectados al servidor o habilitando el acceso SSH. Una vez dentro hay que señalarle al pfSense dónde están los paquetes de Samba que queremos descargar, por lo que corremos:

setenv PACKAGESITE “http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/ports/i386/packages-8.3-release/Latest/

Fíjense que corresponda a la arquitectura que les corresponda, en mi caso, es i386. Estuve un rato googleando para encontrar el ftp que corresponde, puede llegar a pasarles lo mismo, porque aparentemente la URL del sitio ha cambiado desde la documentación que yo conseguí… pero bueno, al día de la fecha es esa. Siguiente comando:

pkg_add -r samba36

En el ftp hay muchas versiones (3.4, 3.6, 4-devel), pueden verlos todos visitando la URL con el navegador. El comando va a demorar un rato y les va a instalar el paquete de Samba. Ahora hay que configurar algunos archivos. Tienen dos opciones, o con vi directamente en el shell o mediante el webConfigurator, sólo tienen que ir a Diagnostics -> Edit File. Este es el archivo:

/usr/local/etc/smb.conf

Busquen la línea que dice “security = user” y abajo pongan esto:

map to guest = bad user

Esto permite que Samba no pida contraseña al browsear el recurso. Lo siguiente que hay que hacer es ir hasta los ejemplos finales del archivo y agregar la carpeta compartida. Mi archivo dice esto:

[bolsa]
comment = Espacio para compartir
path = /bolsa
available = yes
browsable = yes
writable = yes
create mask = 0666
directory mask = 0777
read only = no
public = yes
guest ok = yes

Puedo haber exagerado con algunos flags, pero ya saben lo que dicen…. SI ANDA NO LO TOQUES. Por supuesto, el directorio /bolsa tiene que existir. En el shell hacen esto:

mkdir /bolsa
chmod 777 /bolsa

Y ya que están escriban esto:

touch /etc/rc.conf.local

Es un archivo que necesitamos y que es probable que no exista. Una vez creado lo editan y le agregan esto:

samba_enable=”YES”
nmbd_enable=”YES”
smbd_enable=”YES”
winbindd_enable=”YES”

El chabón al que le copié la guía se cruzó con un bug de Samba, y como es muy groso tuvo la generosidad de decirnos lo que hizo. Básicamente cuando Samba arranca con el sistema intenta crear los archivos PID en un directorio que no existe porque está en /var, y como algunos de ustedes saben /var se limpia cada vez que la máquina reinicia. Hay dos formas de arreglarlo, la primera es editar el script de inicio de samba y cambiar la línea “pidfile=”/var/run/samba/${name}${pid_extra}.pid” por un path que exista persistentemente o bien hacen lo siguiente, editan el archivo:

/cf/conf/config.xml

Busquen la línea que dice: <dnsallowoverride/> (debería estar entre los tags <system> y </system>) y directamente abajo le agregan esto:

<shellcmd>mkdir /var/run/samba</shellcmd>

Esto hace que el shell cree la carpeta ni bien arranca y samba puede crear el archivo tranquilamente. Ahora sólo tienen que copiar el script de samba para iniciar con el equipo mediante:

cp /usr/local/etc/rc.d/samba /usr/local/etc/rc.d/samba.sh

Listo. Ya estamos. Pueden iniciar el servicio con:

/usr/local/etc/rc.d/samba start

Pero a mi me gusta más reiniciar el servidor. Debería funcionar todo sin problemas. Cuando mucho tendrán que retocar un poco las flags del archivo smb.conf, pero por lo menos a mi me anduvo sin chistar.

Si les sirvió, dejen un comentario por favor así por lo menos me entero de que no escribo al pedo.

Ah! La guía originál y algunos links que pueden ayudar:

http://www.laxdal.org/node/310
https://wiki.samba.org/index.php/Public_Samba_Server
https://wiki.archlinux.org/index.php/Samba/Tips_and_tricks

Saludos

pfSense 2.1.5 + squid 2.7.9 + squidGuard 1.4_4 para bloquear tráfico

Hoy terminé de hacer andar, al menos en la comodidad de mi laboratorio de máquinas virtuales, un pfSense que hace de proxy transparente para bloquear sitios de porno y demás a pedido de un colegio.

Lo primero es, por supuesto, bajar pfSense, e instalarlo en la correspondiente versión para su arquitectura. Configurarlo es bastante simple, siempre recordando que el servidor con pfSense está entre medio entre la WAN y la LAN – ergo, tienen que tener 2 interfaces de red -. Durante la instalación nos pregunta qué nombres les queremos dar a estas y hay que ponerle em0 (eso es un CERO, no una O, chiste al margen) y em1 a la interfaz que da a la LAN.

Acto seguido basta con mirar esta completísima y conveniente guía en video para instalar squid y squidGuard:

http://www.youtube.com/watch?v=H-6_13P8pS8

PERO OJO, el video no se corresponde exactamente con las versiones que puse en el titulo. La mayor diferencia que he encontrado con el video es que a la hora de configurar la blacklist, no se hace desde el squid sino desde el squidGuard; simplemente instalen el paquete de squid, configúrenlo como proxy transparente, hagan la ACL para la red local, y vayan al squidGuard y configuren como dice esta documentación.

Al principio los servicios no arrancaron. Reinstalé el squid desde el Packet Manager y salió andando.

También tengo instalado un certificado propio que me pedí a una de las entidades certificadoras. Esto es para evitar que al configurar el proxy transparente el navegador me lo detecte como un ataque MITM. No sé si esto está andando bien o no y me voy a dar cuenta mañana, por lo que apenas tenga un update lo vengo a comentar acá.

Ejecutar un script como sudo sin pedir contraseña

Esto lo bajo al blog porque francamente estuve un rato largo (como 15 minutos!) para poder encontrarlo, y después de putear un poco demasiado logré encontrarle la vuelta. La plataforma es Linux Mint (Debian).

Lo primero que hay que hacer es, por supuesto, crear el script. En mi caso es un script para modificar la deriva del reloj que por alguna extraña razón se viene dando en uno de mis servidores. El script está en /home/usuario/updDate.sh , y corre estos dos comandos:

ntpd -gq
hwclock -w

ntpd hace un query a los servidores NTP para obtener la fecha y hora correcta, el flag -g obliga al demonio a corregir la hora si o si (porque si es más de, creo, 600ms no lo hace) y el flag -q cierra el demonio una vez finalizada la operación. hwclock -w escribe la fecha y hora actual al reloj del sistema (esto lo hago para que las máquinas virtuales dentro de este servidor tomen la hora correcta)

Lo siguiente que hay que hacer es editar como root el archivo /etc/sudoers y agregar esta línea al finál:

usuario ALL=NOPASSWD: /home/usuario/updDate.sh

Esto hace que al ejecutar ese script con sudo como el usuario “usuario”, no te pida password. Acto seguido lo que hice fue cronear este job. Listo el pollo.

The Fappening: el lado obscuro de La Nube

Desde el sábado pasado se dió a conocer en toda la Internet una noticia más que interesante: se habían filtrado fotos de muchas chicas lindas y famosas. Se filtró a través de 4chan y Reddit no demoró en ponerle un sobrenombre a todo el asunto, que tenía que ser algo mezcla de troll y épico y así quedó… “The Fappening”

Debo confesar, hace días que no puedo parar de reirme de los comentarios que leo, las vueltas y los tumbos que todo el asunto está dando.
Primero crearon un subreddit, al primer día ya tenía más visitas que la página principal de Reddit; en menos de 3 días ya tenía 100.000 suscriptores. Los otros subreddits estaban vacíos.
Incluso alguien “hizo las matemáticas” y llegó a una interesantísima conclusión.
Después alguien tuvo la brillante idea de revisar el twitter de una de las afectadas y se encontró con que habia donado alguna vez dinero para una asociación pro lucha contra el Cáncer de Próstata; y alguien dijo… “guise… por qué no donamos todos a esta asociación ya que, de cierta forma, ella nos está ayudando a nosotros a combatir el cancer de próstata?”. BANG. Éxito instantáneo. ¿Y qué hicieron los de la Asociación? Largaron una comunicado y devolvieron todas las donaciones provenientes de Reddit porque… según ellos, no era digno.
¿Qué hizo Reddit? Gritar “felicitaciones muchachos, oficialmente somos PEORES QUE EL CANCER” y buscar otro lugar donde dejar sus donaciones. Water.org fue esta vez, y… quién diría… ellos también rechazaron las donaciones. Los comentarios de este segundo suceso son, sinceramente, hilarantes.

Y ahí andan, de un lado para el otro, trolleando a todo Internet, a las dueñas de las fotos y por sobre todo a cualquier gil de gominola que se le ocurre opinar del asunto. Como siempre la nota la dan los canales de desinformación, diciendo, por ejemplo, que 4chan es UNA PERSONA, posiblemente un ADMINISTRADOR DE SISTEMAS (lo dijo un “especialista en tecnología”, para peor).

Lo lógico de esperar de acá en más es que se arme una bataola de la gran cajeta del mono en torno a la Privacidad. Es lógico porque parece que finalmente algunas personas están empezando a comprender que sus fotos no están guardadas en una cajita segura en el sótano. No, están en “La Nube”.

Lo que dice el puterío es que fue un “hack” de iCloud, el sistema de Apple para mantener un backup de todos los videos y fotos de sus teléfonos en la Nube y así poder guardar las fotos de tus hijos y perro para siempre. Y también de la vez que tu novio te sacó una foto medio en pelotas con el iPhone. Los puteríos se ponen todavía más interesantes cuando te encontrás con que, supuestamente, hay un círculo de Hackers que se dedica específicamente a reventar famosos e intercambiar fotitos entre sí; así como hace 4chan en este momento con comics de hentai, pero con OC [Original Content] de “celebridades”… y por supuesto obtenido de primera mano – más jugoso aún es que parece que con herramientas policiales que se desarrollaron específicamente para esto . Y por supuesto, esta es la explicación más lógica. Apple ya se lavó las manos, asique por supuesto el moco le va a quedar pegado al malo de turno. Y si estas leyendo este blog y esta oración ya sabés perfectamente quiénes son los malos de turno.

El problema es… ¿quién tiene la culpa? ¿el chancho o el que le da de comer?

El primer argumento que sale a la luz es “no subas tus fotos”. Y es lógico, pero por lo que he leído desactivar iCloud es bastante engorroso. Yo en lo personal me encargué de evitar que mi celular sincronize cualquier cosa, pero yo soy un usuario “avanzado” y de paso no creo que nadie tenga ganas de ver fotos mías sacando músculo adelante del espejo. Pero si hay algo que tiene la tecnología es que es como las enfermedades, no hace distinciones. No existe un “Seguridad Informática 101 para Potenciales Estrellas del Espectáculo”, y siendo realistas, quizás tampoco vaya a existir jamás.

El segundo argumento es “bueno, si alguien se quiere meter en tus cosas, probablemente lo vaya a hacer igual. Y también es lógico. Hay quienes dicen que las medidas de seguridad en las casas están hechas para prevenir un gran número de intrusiones, pero el que quiere entrar… entra igual Para esos casos existen los seguros. Pero no tenemos seguros cuando la información privada sale a la calle. Ni tampoco quizás vaya a existir jamás.

Entonces… ¿qué queda? En mi opinión, el clásico llamado al uso responsable y consciencia. Hay un viejo dicho en Internet que dice que si tu información entra en algún tipo de dispositivo, debe ser automáticamente considerada PUBLICA. Tus fotos. Tus facturas. Tus notitas de amor. Tu hatemail. Todo lo que tenga un contraparte digital es potencialmente público.
Esta es la única forma de prevenir este lado oscuro que estamos viendo de la Nube. No es un mal que se cure con una venda, es un mal que se cura con prevención. NO USEN EL MUNDO DIGITAL PARA GUARDAR SECRETOS. Si querés guardar una experiencia, guardala en tu memoria. Como fotógrafo, entiendo que algunas experiencias nunca deberían ser retratadas porque sólo se hacen carne al experimentarlas.

Por lo pronto, yo me voy a ir a seguir riendo de todo esto que está sucediendo que es, por lejos, uno de los eventos más graciosos ocurridos alguna vez en Internet después del Numa Numa.

QUICKFIX: Cambiar la resolución de Lubuntu corriendo dentro de una VM de VirtualBox

Hoy necesité instalar una VM de Lubuntu 14.04 (Ubuntu con LXDE) en VirtualBox 4.3. Para mi sorpresa cuando la VM arrancó la resolución era de 640×480 y no se podía cambiar por nada más grande. Si bien no la necesito para hacer nada en especial, mañana voy a estar mostrando esta pantallitita en una reunión y queda como el culo. No necesito una solución definitiva y mucho menos linda, simplemente quiero que la pantalla sea un poco más grande para mañana poder mostrarlo.

Escarbé un rato y muchos hablan de modificar este script:

etc/xdg/lxsession/LXDE/autostart

Pero resulta que por alguna razón que desconozco mi Lubuntu no tiene la carpeta LXDE bajo lxsession, sino 2 otras carpetas que tienen cada una su archivo autostart. Modificarlos no sirve de nada asique tuve que seguir escarbando. La solución vino de la mano de este muchacho.

La solución esta quizás no sea la más limpia, y desconozco totalmente por qué funciona, pero FUNCIONA. We might as well live with it.

Lo que hay que hacer es instalar xdiagnose [ apt-get install xdiagnose ] y ejecutarlo. Te va a tirar una ventana que tiene 3 checkbox bajo Depuración, hay que tildarlos a los 3 y darle Aplicar y después reiniciar. Listo, ya debería haber listados en los Ajustes del Monitor tres nuevas resoluciones, entre ellas 1024×768 que a mi me viene bárbaro para lo que necesito.

 

Esto fue Mortal Kombat para pleysteishion y espero que les haya gustado.

CHAU

"Tell me and i forget, teach me and i may remember, involve me and i learn." – B. Franklin