-- Magú
miércoles, 5 de noviembre de 2008
miércoles, 29 de octubre de 2008
Eso explica muchas cosas
El sexo y el poder ofuscan a los inteligentes
y vuelven locos a los tontos.
--
Ángeles Mastretta
y vuelven locos a los tontos.
--
Ángeles Mastretta
lunes, 27 de octubre de 2008
Me re lleva
El pasado sábado 4 de octubre tuve que cambiar el servidor de squid: un problema documentado con el error (110) y (111) me obligaron a jubilar un RHEL3 y cambiarlo por un RHEL5. El problema pudo terminar allí, si no fuera porque el servidor también contenía unas bases de datos. Como era de esperarse, se rompieron varias cosas. Entre ellas el infame programa del Informe Anual.
Para el jueves 9 de octubre el informe anual aún no quedaba. Revisé el respaldo y los datos están allí. Envié una copia del pg_dump a la persona encargada del informe anual. Sabiendo que la fecha límite para el informe es el 5 de noviembre avisé el lunes 13 de octubre que podíamos seguir utilizando el servidor viejo -con otra dirección IP- sin tener que cambiar otra cosa en los programas que la dirección IP del dbhost.
Hoy 27 de octubre, me piden arreglar el sistema "por que ya les urge". Me re lleva el chanfle. Por eso avisé hace quince días, para evitarme la munga de reparar un sistema que no conozco. En fin. Échale la culpa al sysadmin.
Eso sí, el año que entra compramos un servidor nuevo, le ponemos lo necesario, lo entregamos en custodia a quién corresponda y nos olvidamos del asunto.
Para el jueves 9 de octubre el informe anual aún no quedaba. Revisé el respaldo y los datos están allí. Envié una copia del pg_dump a la persona encargada del informe anual. Sabiendo que la fecha límite para el informe es el 5 de noviembre avisé el lunes 13 de octubre que podíamos seguir utilizando el servidor viejo -con otra dirección IP- sin tener que cambiar otra cosa en los programas que la dirección IP del dbhost.
Hoy 27 de octubre, me piden arreglar el sistema "por que ya les urge". Me re lleva el chanfle. Por eso avisé hace quince días, para evitarme la munga de reparar un sistema que no conozco. En fin. Échale la culpa al sysadmin.
Eso sí, el año que entra compramos un servidor nuevo, le ponemos lo necesario, lo entregamos en custodia a quién corresponda y nos olvidamos del asunto.
martes, 21 de octubre de 2008
sha1sum con la mac
¿Cómo verificas que se bajó bien el DVD de Fedora en una Mac OS X?
# openssl dgst -sha1 Fedora-9-x86_64-DVD.iso
SHA1(Fedora-9-x86_64-DVD.iso)= f92576227484a4eeda0e86a497836c67c34d20ef
En realidad, también sirve en Linux, en caso de que no tengas instalado el sha1sum.
ACK: Altamar.
# openssl dgst -sha1 Fedora-9-x86_64-DVD.iso
SHA1(Fedora-9-x86_64-DVD.iso)= f92576227484a4eeda0e86a497836c67c34d20ef
En realidad, también sirve en Linux, en caso de que no tengas instalado el sha1sum.
ACK: Altamar.
¿Cuál es la edad promedio de los académicos del CIE?
sica2007=# SELECT AVG(age) FROM
sica2007-# (SELECT age(rfc2date) FROM
sica2007(# (SELECT rfc2date(rfc) FROM datos_per WHERE active AND acad)
sica2007(# AS foo)
sica2007-# AS bar;
avg
-----------------------------------------
47 years 6 mons 29 days 26:50:50.847458
(1 row)
Da gusto saber que uno todavía está jóven.
miércoles, 15 de octubre de 2008
martes, 9 de septiembre de 2008
Acer Aspire 4320
Por alguna extraña razón, el lector de discos compactos dejó de funcionar... en Hasefrog Vista. Como era de esperarse, en Fedora Linux el CD-ROM funcionaba muy bien.
Le apliqué no sé cuántas veces los updates, poner y quitar no se cuántos drivers, y cuanta cosa se me ocurrió. Hasta intenté restaurar el equipo al estado inicial del fabricante. Afortunadamente no lo logré. Pero eché a perder el arranque. Tuve que arreglarlo según indica http://support.microsoft.com/kb/927392:
bootrec /fixmbr
bootrec /fixboot
Creo que la segunda orden no era necesaria, pero ya entrado en gastos ¿pues a quien le importa?
Después de preguntarle al Oráculo, encontré la solución en http://support.microsoft.com/kb/314060. Es un documento de XP, pero funcionó en Vista.
Hay que quitar la entrada UpperFilters de la subclave del Registro {4D36E965-E325-11CE-BFC1-08002BE10318}. ¡Pero por supuesto! ¿Cómo no lo ví antes? Si está clarísimo.
Ya funciona el CD-ROM.
Odio el maldito registro de Windows.
Le apliqué no sé cuántas veces los updates, poner y quitar no se cuántos drivers, y cuanta cosa se me ocurrió. Hasta intenté restaurar el equipo al estado inicial del fabricante. Afortunadamente no lo logré. Pero eché a perder el arranque. Tuve que arreglarlo según indica http://support.microsoft.com/kb/927392:
bootrec /fixmbr
bootrec /fixboot
Creo que la segunda orden no era necesaria, pero ya entrado en gastos ¿pues a quien le importa?
Después de preguntarle al Oráculo, encontré la solución en http://support.microsoft.com/kb/314060. Es un documento de XP, pero funcionó en Vista.
Hay que quitar la entrada UpperFilters de la subclave del Registro {4D36E965-E325-11CE-BFC1-08002BE10318}. ¡Pero por supuesto! ¿Cómo no lo ví antes? Si está clarísimo.
Ya funciona el CD-ROM.
Odio el maldito registro de Windows.
grub>
¡Me chachis! Estas instalaciones duales siempre son un dolor de cabeza. ¿Quién le manda a los usuarios cambiar las particiones?
rootnoverify (hd0,0)
chainloader +1
boot
martes, 2 de septiembre de 2008
cryptofs
Hace unos días bajé unos vídeos de LAWALOCA. Como no podía dejarlos en el sistema de archivos así como así, me puse a la tarea de crear un Sistema de Archivos Cifrado.
Sí, se dice "cifrado", no "encriptado". ¿No se dice, desde hace mucho, decifrar un mensaje secreto? Y si no estás de acuerdo, pasa al siguiente blog.
Si bien es cierto que Fedora 9 ya te permite realizar instalaciones con sistema de archivos cifrados, la idea era utilizar un dispositivo "portátilizador" USB para el efecto.
Sea:
/dev/sdc el dispositivo portatilizador
Si la paranoia es grande, lo mejor es empezar borrando el dispositivo con:
# wipe /dev/sdc
O en su defecto,
# dd if=/dev/zero of=/dev/sdc
Luego, hay que sembrar el dispositivo portatilizador con la suficiente información para despistar al enemigo:
# dd if=/dev/urandom of=/dev/sdc
Esto tomará mucho tiempo, y agotará la entropía del sistema. Lo mejor es utilizar un dispositivo generador de números aleatorios, como el que viene en la fit-pc. geode-rng.ko. Esto es especialmente importante en el siguiente paso: la generación de la llave criptográfica. Adicionalmente, la fit-pc incluye un coprocesador criptográfico geode-aes.ko el cual funciona en Fedora 9 y está disponible según /proc/crypto:
Una vez que se recupere la entropía, (o usando el generador de números aleatorios), procedemos a preparar el dispositivo portatilizador:
# cryptsetup --verbose --cipher 'aes-cbc-essiv:sha256' --key-file=/dev/random --hash=$(mcookie) --key-size 128 --verify-passphrase luksFormat /dev/sdc
El tamaño de la llave seleccionado es un albur entre velocidad y seguridad. Si la llave es muy pequeña, es posible que una agencia de tres letras (no, la PFP no está en esa lista) sea capaz de romper el código y descifrar el dispositivo. Una llave demasiado grande, por el contrario, requerirá de mucho tiempo para realizar el cifrado/descifrado de datos, haciendo impráctico el ejercicio.
Para cuestiones ordinarias, 128 bits son suficientes para detener la curiosidad femenina. Unos 256 bits parece ser lo normal en estos tiempos de procesadores multi-núcleo. Más de 512 bits... eres terrorista, pedófilo; o peor aún: tu perteneces a una agencia de tres letras.
Una vez seleccionado el tamaño de llave, hay que proporcionar la frase de paso (passphrase), la cual, una vez más, debe tener la sufiente entropía. Una cadena se rompe por el eslabón más débil, así que escoge una buena frase.
El dispositivo ya se encuentra "formateado", ahora hay que establecer la conexión entre el dm-crypt y el dispositivo.
# cryptosetup luksOpen /dev/sdc cryptousb
Esto crea un dispositivo en /dev/mapper con nombre cryptousb. Es el dispositivo sobre el cual vamos a crear el sistema de archivos cifrado. El resto de las operaciones son como con cualquier otro sistema de archivos convencional:
# mke2fs -Lcryptousb /dev/mapper/cryptousb
# mount /dev/mapper/cryptousb /mnt/cryptousb
# mv -a /el/contenido/de/lawaloca /mnt/cryptousb/todo/lo/naco/es/chido
Antes de extraer el dispositivo portatilizador, es necesario desconectar todos los componentes del núcleo:
# umount /mnt/cryptousb
# cryposetup luksClose /dev/mapper/cryptousb
# rmmod usb-storage
Luego, hay que llevar el dispositivo portatilizador a la computadora del compañero ñero. Afortunadamente, de aquí en adelante el escritorio de Fedora 9 será capaz de darse cuenta que se trata de un dispositivo cifrado y nos preguntará la frase de paso para poder utilizarlo en el entorno convencional del escritorio.
ACK: A fesom por las sugerencias para escribir este artículo, y otros motivos para tener un dispositivo cifrado. demonoid.
Sí, se dice "cifrado", no "encriptado". ¿No se dice, desde hace mucho, decifrar un mensaje secreto? Y si no estás de acuerdo, pasa al siguiente blog.
Si bien es cierto que Fedora 9 ya te permite realizar instalaciones con sistema de archivos cifrados, la idea era utilizar un dispositivo "portátilizador" USB para el efecto.
Sea:
/dev/sdc el dispositivo portatilizador
Si la paranoia es grande, lo mejor es empezar borrando el dispositivo con:
# wipe /dev/sdc
O en su defecto,
# dd if=/dev/zero of=/dev/sdc
Luego, hay que sembrar el dispositivo portatilizador con la suficiente información para despistar al enemigo:
# dd if=/dev/urandom of=/dev/sdc
Esto tomará mucho tiempo, y agotará la entropía del sistema. Lo mejor es utilizar un dispositivo generador de números aleatorios, como el que viene en la fit-pc. geode-rng.ko. Esto es especialmente importante en el siguiente paso: la generación de la llave criptográfica. Adicionalmente, la fit-pc incluye un coprocesador criptográfico geode-aes.ko el cual funciona en Fedora 9 y está disponible según /proc/crypto:
Una vez que se recupere la entropía, (o usando el generador de números aleatorios), procedemos a preparar el dispositivo portatilizador:
# cryptsetup --verbose --cipher 'aes-cbc-essiv:sha256' --key-file=/dev/random --hash=$(mcookie) --key-size 128 --verify-passphrase luksFormat /dev/sdc
El tamaño de la llave seleccionado es un albur entre velocidad y seguridad. Si la llave es muy pequeña, es posible que una agencia de tres letras (no, la PFP no está en esa lista) sea capaz de romper el código y descifrar el dispositivo. Una llave demasiado grande, por el contrario, requerirá de mucho tiempo para realizar el cifrado/descifrado de datos, haciendo impráctico el ejercicio.
Para cuestiones ordinarias, 128 bits son suficientes para detener la curiosidad femenina. Unos 256 bits parece ser lo normal en estos tiempos de procesadores multi-núcleo. Más de 512 bits... eres terrorista, pedófilo; o peor aún: tu perteneces a una agencia de tres letras.
Una vez seleccionado el tamaño de llave, hay que proporcionar la frase de paso (passphrase), la cual, una vez más, debe tener la sufiente entropía. Una cadena se rompe por el eslabón más débil, así que escoge una buena frase.
El dispositivo ya se encuentra "formateado", ahora hay que establecer la conexión entre el dm-crypt y el dispositivo.
# cryptosetup luksOpen /dev/sdc cryptousb
Esto crea un dispositivo en /dev/mapper con nombre cryptousb. Es el dispositivo sobre el cual vamos a crear el sistema de archivos cifrado. El resto de las operaciones son como con cualquier otro sistema de archivos convencional:
# mke2fs -Lcryptousb /dev/mapper/cryptousb
# mount /dev/mapper/cryptousb /mnt/cryptousb
# mv -a /el/contenido/de/lawaloca /mnt/cryptousb/todo/lo/naco/es/chido
Antes de extraer el dispositivo portatilizador, es necesario desconectar todos los componentes del núcleo:
# umount /mnt/cryptousb
# cryposetup luksClose /dev/mapper/cryptousb
# rmmod usb-storage
Luego, hay que llevar el dispositivo portatilizador a la computadora del compañero ñero. Afortunadamente, de aquí en adelante el escritorio de Fedora 9 será capaz de darse cuenta que se trata de un dispositivo cifrado y nos preguntará la frase de paso para poder utilizarlo en el entorno convencional del escritorio.
ACK: A fesom por las sugerencias para escribir este artículo, y otros motivos para tener un dispositivo cifrado. demonoid.
martes, 26 de agosto de 2008
ntfs-3g
Hoy me di cuenta que que hay mucho que escribir en este blog. Sobre el frustrado regreso a clases. O sobre las tristes olimpiadas. Pero como no hay mucho tiempo, aprovecho para hablar un poquito de hasefrog y cómo ahorrarse tiempo, dinero y esfuerzo usando Linux para repararlo.
Regresó un investigador de su estancia sabática, descubriendo que su máquina de Hasefrog-XP marcaba unos errores del disco duro. En realidad, se trataba de mensajes de advertencia del SMART (¡ah! ¡no! ese es el Super Agente 86), me refiero a S.M.A.R.T.: Self-Monitoring, Analysis, and Reporting Technology (sic), indicando que el disco duro en cuestión estaba a punto de estirar la pata.
Esperando no tener que re-instalar Hasefrog XP, y mucho menos tratar de hacer un respaldo de información (aún hay usuarios que no saben que existe una carpeta que se llama "Mis Documentos") decidimos utilizar las herramientas NTFS-3G para copiar la información del disco viejo (de 80GB) a un disco nuevo (de 160GB), y de paso, utilizar toda la capacidad del disco nuevo.
Sea:
/dev/sdb el disco viejo con hasefrog XP
/dev/sdc el disco nuevo
Primero, copiamos la tabla de particiones:
Hay que quitar y volver a poner el adaptador USB para que se registren los cambios.
Luego, copiamos el disco viejo en el nuevo:
En seguida, con fdisk asignamos todo el espacio del disco a la particion NTFS (esto lo pudimos haber hecho desde el principio, pero no se nos ocurrió en ese momento).
Finalmente, le cambiamos el tamaño al ntfs con:
Como era de esperarse, el nuevo disco no arrancó. Tal vez nos faltó información del MBR. Yo creo que nos faltó copiar el sector de arranque de la partición primaria. En realidad, ¿a quién le importa? Utilizando el CD-ROM de instalación del hasefrog XP entramos a "recuperar el sistema".
¡Tará! El hasefrog XP regresó.
Larga vida a Linux, que sirve para hacer más fácil el trabajo en hasefrog XP.
Regresó un investigador de su estancia sabática, descubriendo que su máquina de Hasefrog-XP marcaba unos errores del disco duro. En realidad, se trataba de mensajes de advertencia del SMART (¡ah! ¡no! ese es el Super Agente 86), me refiero a S.M.A.R.T.: Self-Monitoring, Analysis, and Reporting Technology (sic), indicando que el disco duro en cuestión estaba a punto de estirar la pata.
Esperando no tener que re-instalar Hasefrog XP, y mucho menos tratar de hacer un respaldo de información (aún hay usuarios que no saben que existe una carpeta que se llama "Mis Documentos") decidimos utilizar las herramientas NTFS-3G para copiar la información del disco viejo (de 80GB) a un disco nuevo (de 160GB), y de paso, utilizar toda la capacidad del disco nuevo.
Sea:
/dev/sdb el disco viejo con hasefrog XP
/dev/sdc el disco nuevo
Primero, copiamos la tabla de particiones:
# dd if=/dev/sdb of=/dev/sdc bs=1k count=1
Hay que quitar y volver a poner el adaptador USB para que se registren los cambios.
Luego, copiamos el disco viejo en el nuevo:
# ntfsclone --rescue --overwrite /dev/sdc1 /dev/sdb1
En seguida, con fdisk asignamos todo el espacio del disco a la particion NTFS (esto lo pudimos haber hecho desde el principio, pero no se nos ocurrió en ese momento).
Finalmente, le cambiamos el tamaño al ntfs con:
# ntfsresize --bad-sectors /dev/sdc1
Como era de esperarse, el nuevo disco no arrancó. Tal vez nos faltó información del MBR. Yo creo que nos faltó copiar el sector de arranque de la partición primaria. En realidad, ¿a quién le importa? Utilizando el CD-ROM de instalación del hasefrog XP entramos a "recuperar el sistema".
C> chkdsk /f /r
C> fixmbr
C> fixboot
¡Tará! El hasefrog XP regresó.
Larga vida a Linux, que sirve para hacer más fácil el trabajo en hasefrog XP.
lunes, 18 de agosto de 2008
Gustavo Moreno Toribio LADRÓN de imágenes
Apoyando a Gato Azul con este asunto del uso inadecuado de su fotografía Llama en Machupicchu por parte del LUSER Gustavo Moreno Toribio.
Sólo faltaba que las firmas MD5SUM fueran iguales:
b47df176a72d0caeb3ec166227b24c5e 2293559521_57bb118dce_b.jpg
e9cdd38474f6b462270a918f2991faa0 2683344802_0660f17d6b_o.jpg
Al menos se tomó la molestia de "retocarla" en Photoshop, al parecer, su única habilidad.
Ánimo, Gato Azul.
N.del E. Sí ya sé que esto no es de Linux, pero ¡no somos máquinas!
Suscribirse a:
Entradas (Atom)