Archivo de la categoría: Computación

Android como plataforma de desarrollo

Hola a todos,

Trayéndoles las siguientes notas del curso de Android, ahora vamos a conocer a Android como plataforma de desarrollo. Conoceremos las herramientas con las que podemos producir aplicaciones Android, cómo se administra la ejecución de las aplicaciones, cómo y qué se debe tomar en cuenta al desarrollar una aplicación.

Aquí las notas: http://www.nachintoch.mx/teaching/mobile_dev/android-framework.pdf

Debian: cómo enlazar interfaces de red con NAT y usar una PC como “adaptador” WiFi de otro dispositivo sin capacidad inalámbrica

Hola a todos!

Encaminándonos hacia la configuración de un equipo con Debian como router inalámbrico; vamos a aprender a usar NAT para enlazar interfaces de red. Esto es muy útil cuando por alguna razón no podemos establecer un puente de red por alguna razón.

Vamos a aprovechar el ejemplo para establecer un puente de red entre una interfa inalámbrica y otra cableada; lo que nos puede permitir usar una laptop (por ejemplo) como “adaptador” WiFi de una máquina de escritorio.

Sin más, comencemos.


Vamos a valernos de la configuración de DNS y DHCP que hemos trabajado en semanas anteriores. Si no cuentas con un servidor DNS y/o DHCP en el equipo que quieres usar como “adaptador inalámbrico”, puedes consultar los post de semanas anteriores que he escrito al respecto:

Vamos a usar estos servidores para montar una subred tras la interfaz eth0 (en el tutorial, si prefieres usar una tarjeta de red distinta a la que el sistema identifique como eth0; puedes, hacerlo, solo sustituye eth0 por la tarjeta que deseas usar).

Los siguientes pasos asumen que hay un servidor DNS y un servidor DHCP ejecutándose en el equipo local (a usar como “adaptador inalámbrico”) y que tiene dirección IP 10.5.5.1 (si has configurado tu servidor DNS y/o DHCP en uno o varios equipos con direcciones IP distintas; sólo ten encuenta que la dirección IP que uses en la configuración que sigue sea la que tenga asignada la interfaz que va a compartir internet).


Bien. Lo primero que debemos hacer es habilitar el reenvío de paquetes en el kernel. Para ello, editamos el archivo /proc/sys/net/ipv4/ip_foward

1

Debemos asegurarnos que aparezca un “1” en la última línea del archivo. Si “1” es el único contenido en el archivo, con eso basta.

Ahora, vamos a dar de alta la configuración que enmascara el tráfico de red al ser retransmitido de una interfaz a la otra. En consola, usamos el siguiente comando:

# iptables -t nat -A POSTROUTING -s 10.5.5.0/24 -j MASQUERADE

¡Y listo! Estas configuraciones deberían ser suficientes para servir a otros equipos que se conecten directa o indirectamente (a través de un switch opor ejemplo 😉 ) a nuestro equipo. Este tipo de puentes de red no sólo son útiles entre una interfaz wlan0 y otra eht0 para comparitr wifi a través de ethernet; podemos establecer varios puentes de redes de esta forma.

Si queremos revertir estas configuraciones, basta con deshabilitar la retransmisión de paquetes y editar de nuevo el archivo /proc/sys/net/ipv4/ip_foward de forma que ahora el único contenido (o la última línea) sea “0” (cero en lugar de uno).


La próxima semana, aprenderemos a establecer uno quizá más interesante: usar un equipo con Debian como punto de acceso inalámbrico; aka, “compartir wifi”.

Hasta entonces, que el límite sea la imaginación.

Debian y DNS: cómo montar un DNS local

Hola a todos!

Continuando con nuestra serie de publicaciones para el administrador Jr de redes, hoy vamos a empezar a aplicar lo que hemos aprendido sobre DHCP y DNS para configurar una PC con debian como router. Este administrará una subred de forma automática (DHCP) y resolverá nombres de dominio (DNS); tanto nombres de equipos dentro de la subred como equipos externos en Internet.

Para que la subred opere de  forma “autónoma”, es necesario configurar un DHCP, pero para usar un DHCP, necesitamos también un DNS. Si nuestra subred tendrá salida a Internet o no nos interesa definir dominios locales; podemos simplemente usar los DNS de Google 8.8.8.8 y 8.8.4.4

Sino, empecemos a configurar nuestro propio servidor DNS.


Empecemos por descargar elservidor DNS bind9. Con permisos de súper usuario, ejecutamos:

# apt-get install bind9 dnsutils

Ahora, vamos a configurarlo. Empecemos por editar el archivo /etc/bind/named.conf.options

options { 
        directory "/var/cache/bind"; 
 
        forwarders { 
                // Google DNS 
                8.8.8.8; 
                8.8.4.4; 
                // DNS Local 
                192.168.1.1; 
        }; 
 
        dnssec-validation auto; 
 
        listen-on port 53 { 127.0.0.1; 192.168.1.111; }; 
        allow-query { 127.0.0.1; 192.168.1.0/24; }; 
        allow-recursion { 127.0.0.1; 192.168.1.0/24; ::1; }; 
        allow-transfer { none; }; 
 
        auth-nxdomain no;
};

La dirección 192.168.1.111 y las subredes 192.168.1.0, las pongo en el ejemplo tal y cómo me han funcionado en mi configuración. Verifica cuál es la IP que tenga asignada tu equipo y reeplaza 192.168.1.111 por la que tenga y el segmento de red (puedes inferirlo por el tercer número en tu IP) por 192.168.1.0 (es común que algunos routers usen 192.168.0.0).


Ahora; si usamos Network Manager (lo más probable si usas un entorno gráfico), es necesario impedir que actualice automáticamente la configuración de DNS o los cambios que hagamos a continuación NO surtirán efecto. Para esto, editamos el archivo /etc/NetworkManager/NetworkManager.conf Ubicamos la sección [main] y agregamos lo siguiente:

[main]
.
.
.
dns=none
.
.
.

Bien, lo siguiente es asegurarnos que en el archivo /etc/nsswitch.conf aparezca una línea con lo siguiente:

hosts:    files dns

Puede haber más configuraciones entre files y dns o después de dns; pero al menos deben aparecer estas dos en la línea hosts. Si no existen, las escribimos.


Ahora, editamos el archivo /etc/bind/named.conf.local para agregar una zona local:

zone "nachintoch.local" {
    type master;
    file "/etc/bind/db.nachintoch.local";
};

Estamos declarando una zona llamada nachintoch.lan; pero puede tener cualquier otro nombre. Sin embargo, la delcaración de los nombres de dominio locales no aparecen aquí, sino en el archivo que indicamos; en este caso /etc/bind/db.nachintoch.lan Puede tener otro nombre; pero es recomendable crear todos estos archivos en el directorio /etc/bind

Podemos probar que el archivo de configuración sea correcto usando el comando:

# named-checkconf

El contenido de un archivo con declaración de nombres de dominio locales debe verse como el siguiente (en este caso es /etc/bind/db.nachintoch.lan, pero puedes usar otro nombre de archivo):

$TTL 3D
@       IN      SOA     nachintoch.local. root.nachintoch.local. ( 
                        2017070501    ; serie 
                                8H    ; periodo actualizacion 
                                2H    ; reintento de transferencia
                                4W    ; periodo caducidad 
                                1D )  ; TTL 
 ;
                NS      ns            ; direccion del DNS

ns                A       192.168.1.111
nachintoch.local. A       192.168.1.111
server            A       192.168.1.111
router            A       192.168.1.1
gateway           CNAME   router 
gw                CNAME   router 
www               CNAME   server

La configuración anterior indica lo siguiente:

  • El dominio que se está configurando se llama “nachintoch.local” y el responsable de su mantenimiento es root (root.nachintoch.local). Podemos cambiar los nombres a gusto/necesidad.
    • El primer número es la serie de la configuración. Cada vez que se modifique este archivo, es importante incrementarlo para evitar anomalías.
    • Indicamos el tiempo con el que deseamos que otros DNS actualicen esta información.
    • Indicamos el tiempo que puede esperar para volver a intentar tranferir la zona que se está configurando.
    • Indicamos el tiempo tras el que haber actualizado se debe borrar la información de la base de datos del DNS porque puede quedar obsoleta.
    • Indicamos el tiempo de vida de la configuración (tras la que se debería de actualizar).
  • La dirección del servidor DNS. Note que no estamos indicando el nobre de dominio tal cual, sino un “nombre de varable” que se define más adelante. En todo caso, el valor se debe resolver a una dirección IP o un nombre de dominio.
  • Indicamos quién es realmente el DNS.
  • Indicamos quién responde por el dominio. Debe llamarse igual que la zona, o el archivo de configuración no tendrá efecto. Note que se debe terminar con un punto ‘.’
  • Indicamos quién es el servidor.
  • Indicamos quién es el gateway-router.
  • Finalmente, aparece un subdominio conocido; www.

Note que una vez más uso en el ejemplo las IP que me funcionaron en mi configuración (192.168.1.111 es la dirección local de mi laptop y 192.168.1.1 es la dirección local de mi enrutador).

Si nuestro equipo ha obtenido su dirección IP por medio de un DHCP, esta dirección puede cambiar y el DNS empezará a otorgar una IP que posiblemente no tiene un servidor web (que es lo que se espera atienda a www). Para resolver esto, podemos usar una configuración de IP estática, o configurar nuestro servidor DHCP para que le asigne siempre la misma IP al equipo. Veremos cómo hacer esto más adelante en posts futuros.

Podemos comprobar que la configuración sea correcta usando:

# named-checkzone nacintoch.local /etc/bind/db.nachintoch.local

Donde “nachintoch.local” es el nombre de la zona tal y como lo indicamos en el archivo /etc/bind/named.conf y “/etc/bind/db.nachintoch.local” es el archivo asociado a la zona también indicado en /etc/bind/named.conf (y el mismo que acabamos de editar y queremos probar).


Finalmente, modificamos el archivo /etc/resolv.conf; el contenido del archivo debería únicamente contener tres líneas como las del ejemplo (en mi caso, uso nachintoch.local porque es la zona que acabo de definir)

domain nachintoch.local
search nachintoch.local
nameserver 127.0.0.1

 


Ahora podemos reiniciar los servicios (sino usas Network Manager, omite network-manager)

# service networking restart
# service network-manager restart
# service bind9 restart

Y finalmente podemos verificar que el DNS funciona usando

nslookup www

Deberíamos ver una respuesta similar a la siguiente:

Server:         127.0.0.1 
Address:        127.0.0.1#53 
 
www.nachintoch.local    canonical name = server.nachintoch.local. 
Name:   server.nachintoch.local 
Address: 192.168.1.111

Por supuesto estamos viendo reflejada la configuración que acabamos de asentar, lo que en efecto significa que hemos terminado.


¡Y listo! Podemos configurar nuestro router para fijar la IP que se asigna por DHCP a nuestro equipo con DNS e incluir esa misma dirección a los DNS que usa el router. De esa forma, otros equipos en la subred podrán acceder a servicios que ofrezcamos en este equipo usando cómodamente nombres de dominio.

Y por si fuera poco, estas configuraciones pueden usarse también para administrar nuestra propia subred, usando la PC como router; esa es la historia de la próxima semana.


Si queremos deshabilitar las configuraciones que acabamos de dar, podemos simplemente comentar las siguientes líneas del archivo /etc/bind/named.conf.options

options { 
        directory "/var/cache/bind"; 
 
        forwarders { 
                // Google DNS 
                8.8.8.8; 
                8.8.4.4; 
                // Local 
                //192.168.1.1; 
        }; 
 
        dnssec-validation auto; 
 
        //listen-on port 53 { 127.0.0.1; 192.168.1.111; }; 
        //allow-query { 127.0.0.1; 192.168.1.0/24; }; 
        //allow-recursion { 127.0.0.1; 192.168.1.0/24; ::1; }; 
        //allow-transfer { none; }; 
 
        auth-nxdomain no;
};

Y reiniciar bind:

# service bind9 restart

Espero les sea de utilidad. A mi en lo personal se me ocurren muchas cosas divertidas que se pueden hacer con un DNS local; y productivas también, pues podríamos ofrecer servicios web (entre otros) en un salón de clase o una oficina.

Que el límite sea la imaginación. Y el periodo de espera entre actualizaciones del DNS.

Debian: cómo ejecutar un programa o script al inicio del sistema

Hola a todos!

Para posts futuros, estoy trabajando en tutoriales para usar un equipo con Debian como un equipo de red (router + DNS); sin perder la funcionalidad de poderse usar como un sistema de propósito general. Para esto, podemos requerir de ejecutar una configuración que se inicia convenientemente cada vez que arranca el SO.

Hoy les comparto una forma en la que podemos iniciar un programa cualquiera durante el arranque de Debian. Debian define siete estados de ejecución (conocidos como RunLevel) que podemos usar como referencia para ejecutar un programa cuando el sistema cambia de estado. Estos estados son:

0. Apagado. El sistema está operando, pero ha comenzado el procedimiento de apagado (no reinicio).

  1. Un sólo usuario. Se usa principalmente para operaciones de mantenimiento. En este estado, no es posible utilizar todos los recursos del sistema y/o aplicaciones del usuario.

2 a 5. Multiusuario. La instalación por defecto de Debian no define diferencia alguna entre los estados 2, 3, 4 y 5; permitiéndole al usuario del sistema definir estos estados a su conveniencia.

6. Reinicio. El sistema estaba en un estado entre el 1 y el 5 y se está apagando para volver a iniciar instantáneamente. El estado 6 solo abarca la fase de apagado: cuando el sistema reinicia, pasa a estado 1. Esto es importante; ya que por ejemplo, en sistemas multiboot, al reiniciar el sistema el usuario puede elegir cargar un SO diferente.


Para ejecutar un programa durante el cambio de nivel de ejecución, empezamos por crear un archivo (cuyo nombre es indiferente) en el directorio /etc/init.d

Por ejemplo, el siguiente script se llama /etc/init.d/ejemplo.sh (sólo es una instrucción)

#! /bin/bash
### BEGIN INIT INFO
# Provides: Example loging
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 1 2 3 4 5
# Default-Stop: 0 6
# Short-Description: Example
# Description: Created & tested by Nachintoch, contact@nachintoch.mx
#
### END INIT INFO
echo "Loging"
case "$1" in
 start)
 echo `date` >> /home/nachintoch/boot_log.txt
 ;;
 stop)
 echo `date` >> /home/nachintoch/shutdown.txt
 ;;
 *)
 echo "Uso: ejemplo.sh {start|stop}"
 exit 1
 ;;
esac
exit 0

Para asegurarnos que el script será ejecutado, cambiamos los permisos del mismo (puede que requieras permisos de super usaurio):

# chmod 755 /etc/init.d/ejemplo.sh

Ahora, este programa (script) no será ejecutado en ningún momento durante el ciclo de vida del sistema, a menos de que sea invocado manualmente… Necesitamos indicarle al sistema el o los niveles de ejecución en los que queremos que se ejecute.

Para ello, debemos crear un enlace simbólico hacia alguno de los descriptores de estados del sistema. Estos son siete sabios de Hyrule directorios que en principio contienen los scripts que se deben ejecutar cuando el sistema cambia a su nivel…. Digo en principio, porque las buenas prácticas prefieren contener los scripts en el directorio que acabamos de estudiar /etc/init.d, pues es posible que queramos ejecutar el mismo programa durante el arraque y el reinicio; por ejemplo.

Estos siete directorios con los scripts de arranque son:

  • /etc/rc0.d
  • /etc/rc1.d
  • /etc/rc2.d
  • /etc/rc3.d
  • /etc/rc4.d
  • /etc/rc5.d
  • /etc/rc6.d

El sistema usa los nombres de los enlaces simbólicos en los siete directorios mencionados, para distinguir arranques (1, 2, 3, 4, 5) de apagados (0 y 6)… Para simplificar las cosas, al crear el enlace simbólico, podemos usar el comando update-rc.d

# update-rc.d ejemplo.sh defaults

Si queremos evitar que los scripts sean invocados cuando cambie el estado del sistema, podemos eliminar los enlaces simbólicos de los directorios /etc/rcN.d o usar update-rc.d nuevamente:

# update-rc.d -f ejemplo.sh remove

Esto conserva el script original /etc/init.d/ejemplo.sh


Antes de terminar, necesito hacer una aclaración importante. Al terminar de explicar los siete niveles de ejecución de Debian, agregué un asterisco; porque si bien lo que dice ese párrafo es cierto, hay un detalle: no necesariamente la interfaz gráfica forma parte de los estados de ejecución. Esta es una diferencia importante que hacemos con sistemas basados en Debian y otros sistemas operativos como Gentoo o Windows, donde es posible definir el arranque del sistema como el inicio de la interfaz gráfica.

Dependiendo el entorno gráfico que utilices, puedes agregar scripts también para ejecutar durante su arranque. En mi caso, uso GTK+ porque Gnome3 es demasiado pesado para mi portatil de museo. Podemos ejecutar programas al inicio de sesión gráfica de un usuario para ejecutar programas que usan la interfaz gráfica. Yo hago esto para iniciar el salvapantalla, no porque me preocupe que una imagen se quede en el monitor para siempre (es LCD), pero porque dejar el escritorio y regresar para ver la matrix es bastante satisfactorio 🙂

Además, recordemos que los estados de ejecución del 2 al 5 son personalizables; por lo que podemos modificar las instrucciones de ejecución del inicio y del arranque del escritorio para definir uno de estos estados como “entorno gráfico”; pero esa será quizá historia de otro día.


Y bien, esto es lo que hacemos para dar de alta y baja potenciales servicios durante los cambios del ciclo de vida del sistema. Espero les sea de utilidad y que el límite sea la imaginación.

DNS – Domain Name System – ¿qué es? ¿para qué sirve?

Hola a todos!

Este es el segundo post en una serie que pretende ser “la navaja suiza” para el administrador de redes junior (muy junior 😛 ). La semana pasada hablamos sobre DHCP, ese protocolo mágico que nos permite conectarnos a internet de forma instantánea y sin mayores complicaciones.

Sin embargo, en nuestra explicación aparece otro servicio; quizá misterioso para algunos: el DNS. Hoy vamos a entender qué es DNS, para qué sirve y porqué es importante conocerlo antes de configurar un servidor DHCP en nuestro sistema; pues puede que asigne direcciones IP correctamente, pero a menos que sepas de memoria todas las IP que necesitas para navegar por la web, no es de gran utilidad obtener dicha IP automáticamente.


Introducción – El lenguaje habitual VS el lenguaje de las máquinas

Hace algunas décadas que las computadoras dejaron de ser cosas de expertos y cada ves son más user-friendly. La mayoría de los usuarios no usa consolas de comandos, no conecta todos los periferios antes de encender el equipo y no navega la web usando IPs.

Los nombres de dominio; como se le llama a los identificadores de servidores en internet, son una forma de abstraer las IPs y  permitir acceso a servicios en internet sin tener que memorizar las direcciones IP; que pueden ser difíciles de retener (sobre todo las direcciones IPv6) o fáciles de confundir. Los nombres de dominio, pretenden ser un equivalente que las personas podamos recordar fácilmente… Aunque hoy en día la mayoría de las personas ni siquiera usa los nombres de dominio (completamente) y le delega toda la responsabilidad al buscador de Google. Sin ese buscador, la civilización como la conocemos terminaría.

Sin embargo, es importante mencionar que para establecer una conexión por la red, los nombres de dominio no son útiles. Para establecer una conexión por red, es indispensable contar con la dirección IP. Cuando escribimos en el navegador “nachitnoch.mx” o “twitter.com”, el navegador debe resolver el nombre de dominio antes de intentar conectarse a quien sea que sea el equipo con la IP a la que se resuelva el nombre. Y justo allí, es donde entra en acción el DNS.


DNS

DNS o Domain Name System (Sistema de Nombres de Dominio), es una red de clientes y servidores que opera en internet. ¿alguna vez te han comentado que la web no es internet, sino que es un subconjunto de internet? Bueno, es algo parecido.

DNS funciona como un directorio telefónico. Si eres muy joven para recordar uno de estos: es como la app de contactos. Básicamente es un directorio donde se mapea cada nombre en una (o varias) direcciones IP, de forma que el equipo pueda conectarse con un equipo, aún cuando el usuario use el nombre de dominio en lugar de la IP. Bastante conveniente ¿no?

Un servidor DNS tiene definiciones de nombres y las IP a las que resuelven. Por ejemplo:

  • google.com –> 172.217.9.174
  • twitter.com –> 104.244.42.193
  • wordpress.com –> 192.0.78.17
  • nachintoch.mx –> 198.91.81.6

Un cliente DNS, pregunta por la IP asociada a un nombre de dominio. Los clientes DNS más populares son los navegadores web; como firefox, chrome, opera, etc. Hay una herramienta que puede usarse en consola que funciona como cliente DNS, el comando host.

Los DNS están organizados de forma jerárquica y no es indispensable que cada uno tenga el catalogo completo de internet para operar. Si cada servidor DNS usara el catálogo completo de internet; sería un caos: el tráfico que cada servidor DNS generaría para mantener su catálogo actualizado sería muy intenso y no necesariamente todos se mantendrían al día; por lo que habría nombres de dominio que no sabrían resolver o que resolverían en direcciones equivocadas.

Los servidores DNS se limitan a mantener un caché de ciertos servicios que son accedidos por regularidad por los clientes y además se actualizan periódicamente cada cierto intervalo de tiempo. Algunos lo hacen cada 6 horas (por ejemplo, los primarios que deben conocer a todos los sitios .com); mientras que otros lo pueden hacer hasta cada 48 horas (hace un par de años cuando compré mi nombre de dominio, se me indicó que los DNS que conocen los sitios .mx pueden tomarse hasta ese tiempo en actualizarse).

Cuando se le hace una pregunta por un nombre de dominio a un servidor DNS y este no conoce dicho nombre de dominio, entonces el servidor replica la pregunta y espera una respuesta. Eventualmente la pregunta llegará a un servidor DNS que conoce el nombre de dominio en cuestión y responderán en cadena a quién les haya preguntado. El proceso no es lineal: un DNS puede preguntar a varios DNS por un mismo nombre de dominio; y se conformará con la primera respuesta que obtenga.

Como mencioné anteriormente, los DNS están organizados en niveles (de forma jerárquica); de forma que las consultas pueden irse canalizando por nos niveles hasta que algún DNS intermedio; o el responsable por ese subdominio, responda con la dirección adecuada.

La forma en la que se componen los nombres de dominio, indican la estructura jerárquica de los DNS. Por ejemplo:

  • nachintoch.wordpress.com –> Para acceder a este sitio, primero se intenta preguntar al DNS .com (o algún intermedio que lo conozca) quién es wordpress. Luego, se debe preguntar a wordpress quién es nachintoch.
  • es.wikipedia.com –> De forma similar, se debe primero preguntar quién es wikipedia,  para poder preguntarle a Wikipedia quén es “es”.
  • mail.google.com –> Análogamente, se debe conocer primero quién es google; para preguntarle quién es mail.

Si hubiera más subdominios (palabras a la izquierda separadas por punto), se le debe preguntar al último dominio conocido, quién es el subdominio; hasta resolver el nombre completo.


En todo caso, cuando no se logra resolver un nombre de dominio; una conexión a internet fallará, pues recordemos que la IP es indispensable.


DNS va de la mano con DHCP en las configuraciones dinámicas que estudiamos la semana pasada, ya que si el nuevo cliente (huésped) tiene una IP asignada, pero no sabe quién le puede decir quién en el mundo es nintendo.com o cualquier otro nombre de dominio, está bastante atado de manos…

Podemos navegar usando directamente las IP de los sitios y servicios a los que quiera acceder; lo cual en principio es buena idea, ya que solicitar una conexión usando directamente una IP es más rápido que usando un nombre de dominio. Recordemos que las consultas DNS se propagan por la red, y los tiempos de espera de respuesta son arbitrarios (pero nunca infinitos); por lo que debemos sumar estos tiempos de espera al tiempo en general de conexión con un servicio en internet.

Entonces…


¿Porqué resolver nombres de dominio en lugar de usar IPs?

La principal razón para usar nombres de dominio en lugar de IPs (además de su propósito original de hacer accesibles los servicios de internet), es que no todos los servicios están fijados una sola IP eternamente.

Por diversas razones, las direcciones IP de un equipo conectado a internet puede cambiar y si tenías por seguro que google es 172.217.9.174; pues consúltalo de nuevo, pues la dirección pudo haber cambiado.

Esta es la principal razón por la que es preferible siempre hacer conexiones a internet usando DNS; no solo desde el navegador, sino también al “hardcodear” direcciones en programas y aplicaciones.


Y bien; me parece que con esto, puedo dar por concluida nuestra breve introducción a los DNS. Vamos a volver a referirnos a ellos en las siguientes semanas, cuando configuremos primero un servidor DHCP que asume que existe un DNS en algún lado y posteriormente aprenderemos a configurar un servidor DNS incluyendo nombres de dominio locales para nuestras subredes.

Por lo pronto, que el límite sea la imaginación… y el precio del dominio que quieres.

DHCP – Dinamic Host Configuration Protocol – ¿qué es? ¿para qué sirve?

Hola a todos!

En las siguientes semanas, estaré publicando una serie de post que serán la navaja suiza del principiante en administración de redes. Vamos a aprender un poco sobre los protocolos de red más utilizados al configurar una red: DHCP, DNS y posteriormente SNMP, a configurar corta fuegos para un poco de protección; hasta usar una PC como AP inalámbrico o como “antena” de WiFi para otra máquina sin WiFi.

Vamos a empezar por lo que considero lo más básico: DHCP.


Introducción

Quizá alguna vez al curiosear por las configuraciones de tu equipo, te has encontrado que la tarjeta de red puede configurarse de forma automática o estática. La mayoría de los usuarios está tan acostumbrado a que la configuración sea dinámica, que ignoran que es posible usar una configuración estática. Si es tu caso; pues enhorabuena, vamos a aprender qué son ambas configuraciones y cómo usarlas.


IP – Internet Protocol

Cómo quizá muchos de ustedes ya sepan, para que dos equipos de computo puedan comunicarse a través de intenet; es necesario que ambos tengan una dirección IP que en principio es única en todo el mundo. Digo en principio, porque actualmente no hay forma de garantizarlo, pues bajo el estándar IPv4; hay más dispositivos que acceden a Internet que direcciones IP. Si cada uno tuviera una dirección IP única, entonces habría dispositivos que no podrían acceder a internet, porque ya no quedaría ninguna dirección que otorgarles, y puesto que las IP son el equivalente a las direcciones postales, tener dos equipos con la misma IP provocará conflictos entre ambas máquinas.

El “nuevo” (ya no tan nuevo) estándar IPv6, pretende resolver este problema de forma muy “sencilla”: las direcciones de IPv4 son de 32 bits, habilitando un máximo de 4,294’967,295 direcciones IP (sí, hay más dispositivos que quieren acceder a internet que ese número. Cuentan las PC, laptops, smartphones, tablets, PDAs, consolas de videojuegos, smartTVs, etc…)

Las direcciones IPv6 son de 64 bits; es decir, el numero anterior al cuadrado, o 2⁶⁴. Es un número gigantesco. No creo que la humanidad (o las máquinas) tengan que preocuparse por agotar las direcciones IP bajo el estándar IPv6 por un buen rato. Entonces ¿donde está el problema? ¿porqué no simplemente todos usamos IPv6 y nos olvidamos de problemas?

Detrás de toda supercomputadora, hay un sysadmin que no va a dejar que se use más del 5% del procesador en todo tiempo entre todos los usuarios.

Hay varios problemas administrativos para que todos podamos aprovechar IPv6. Para empezar, a forma en la que se asignan direcciones “de alto nivel” es gestionado por una organización llamada ICCAN,  y la forma en la que IPv4 e IPv6 asignan direcciones es diferente, por lo que es necesario que expertos configuren tablas de DNS y routers para direccionar correctamente los paquetes.

Esto también implica que es necesario que todas las organizaciones cambien su configuración e infraestructura para usar IPv6, y esto es costoso; por lo que muchas no lo han hecho.

Trivia: IPv5 si existe, pero fue un desarrollo experimental y nunca se publicó concretamente. Fue inmediatamente sustituido por su sucesor IPv6 por sus diversas mejoras de carácter “urgente”. Windows 9 sí es un mito.


Gracias a la forma en la que funciona el Internet, podemos repetir direcciones IP sin causar anomalías en los equipos con las mismas IP.

El Internet es como las cebollas o como los ogros: tienen capas. Y no, no me refiero precisamente a las capas de “visibilidad” cómo la web, depweb, etc. Esos son cuentos para otra historia.

Las capas a las que me refiero, son capas de redes: subredes. La red que tenemos en casa o en el trabajo es una subred; que puede formar parte de una subred más grande y/o contener otras subredes. El módem o router que el ISP nos pone y conecta a Internet, es lo que se conoce como un Gateway. Un gateway no es más que un equipo de red que transmite mensajes hacia una red externa.

Por ejemplo, en casa, está el módem con IP:168.192.1.1, una PC con IP:192.168.1.2 y su smartphone con IP:192.168.1.3 Suponga que quiere acceder desde su PC a google.com Por ahora, supongamos que el módem sabe de antemano quién es google.com; en un post futuro aprenderemos más sobre DNS; pues los nombres de dominio son medio inútiles para las computadoras: cualquier conexión debe hacerse usando direcciones IP, los nombres de dominio sólo son una forma de hacer direcciones IP “legibles para humanos”.

Suponga que google.com es 172.217.5.174 por lo que el módem envía el mensaje a esa dirección… El origen es 192.168.1.2, hay un dispositivo con la dirección 192.168.1.3 y sólo queda el módem que es 168.192.1.1… Ninguno de los dispositivos en la subred es Google (172.217.5.174).

Cuando esto pasa; que ninguno de los equipos en la subred tiene la dirección de destino, el gateway puede enviar el mensaje por su salida a la red externa. La red externa estará compuesta por otros equipos de red; pudiendo incluir más gateways. El proceso se repetirá hasta que el mensaje llegue a una red que tenga un equipo de red que sepa que en su subred está 172.217.5.174; o que él sea ese equipo destino (Google).

El proceso real es un poco más enredado que esto, pero la idea es la misma.

Espero que lo anterior deje un poco más en claro qué son las subredes. Lo importante que debemos notar aquí, es que si dos equipos en dos subredes distintas tienen la IP 192.168.1.1 (la misma); no pasa nada: los mensajes de los equipos en una subred no alcanzarán a los equipos en otra subred (a menos de que exista una configuración especial).

La desventaja de hacer esto, es que no es posible acceder a equipos en una subred de forma remota (salvo que se realicen configuraciones especiales en el gateway); pero dependiendo de la estructura de la red del ISP, puede ser un poco más complicado (y costoso) que esto.


Direcciones estáticas

Bien, ya sabemos a grandes rasgos como se comunican los equipos por Internet y porqué las IP son tan importantes… Pero ¿de donde vienen? Como mencioné anteriormente, existe una organización que gestiona la asginación de IPs, la YoPuedo ICCAN.

La ICCAN asigna “segmentos” de direcciones IP a países y organizaciones para su uso, No gestiona todas las asignación, sólo las de nivel superior; organizaciones internas en cada país, en coordinación con la ICCAN, son las que terminan de asignar IPs.

Así, grandes corporativos tienen sus propios subsegmentos de direcciones IP en un país, instituciones de educación y gobierno tienen sus propios subsegmentos; y por supuesto: los proveedores de servicios de internet; o ISP por sus siglas en inglés (Internet Service Provider), tienen sus propios subsegmentos de red, que al final son ellos quienes terminan por asignarnos una dirección al contratar sus servicios.

Es importante notar que en general, nos dan una subred privada; es muy probable que tu dirección IP comience con 192.168. y no lo sé por que te esté espiando: eso lo hace el gobierno. Esta subred, la 192.168. es una de las que se usa por defecto para crear subredes privadas que no pueden ser accedidas públicamente desde internet.

Es decir; con las configuraciones habituales, si montas un servidor web en tu casa y copias la dirección IP que tenga asignado el equipo que hospeda al servidor e intentas conectarte a tu página web desde otra red, no podrás hacerlo. Por eso se ofrecen servicios de hosting y las IP públicas tienen un costo adicional; pero en general son ofrecidas también por los ISP para hogares y pequeñas oficinas.


Ahora, es posible que te preguntes cómo es que tu computadora sabe cuál es la IP que le corresponde. Seguramente has usado tu smartphone, tablet o laptop en un café o en una plaza con WiFi y jamás te has preocupado por configurar o preguntar por la IP que deberías usar… ¿cómo es que la máquina lo sabe?

Screenshot_2017-06-26-19-02-13

¿Qué clase de brujería es esta?

Pues parafrasee desde el principio: hay dos formas de asignarle una dirección IP a un equipo; de forma estática o de forma dinámica.


El método estático, es el más simple. Consiste en indicar de forma “permanente” la dirección que usará una interfaz de red.  Este tipo de configuraciones son usualmente usadas solo en redes de organizaciones y la mayoría de los usuarios no la usa.

Sin embargo, es muy probable que el modem o router que tengas en casa te permita configurarlo para usar direcciones IP estáticas; por lo que puedes intentarlo si quieres. Para configurar una IP estática, necesitas conocer la dirección física de la interfaz de red que vas a conectar. Esta es la “dirección MAC” que aparece listada en los detalles de una conexión.

Las direcciones MAC son asignadas por los fabricantes de las interfaces de red y se supone que estas sí son únicas en el mundo; pero todo puede pasar en este mundo.

Así, si indicarías al router a través de su interfaz de configuración (usualmente una pequeña web a la que puedes acceder si pones en el navegador la dirección de la “puerta de enlace”; como se suele mostrar al gateway) la dirección MAC de tu interfaz; no importa si es WiFi o Ethernet y una dirección IP (única en tu subred), puedes indicar explícitamente esta configuración también en tu equipo y conectarte a internet con una IP estática.

El pase de diapositivas requiere JavaScript.

En Windows podemos hacer estas configuraciones en Centro de redes > Cambiar a configuración del adaptador


Direcciones dinámicas – DHCP

Es posible que salvo que hayas tomado un curso de redes o por alguna razón hayas tenido que configurar una red, jamás hayas usado las configuraciones anteriores. Por defecto, hoy en día todos los dispositivos de red esperan ser configurados automáticamente, lo que nos permite desentendernos de todo lo anterior y simplemente esperar a que desaparezca el mensaje “obteniendo dirección IP” (que de hecho, indica que los equipos están intercambiando los parámetros de configuración de red para que puedas leer este blog y ver muchas fotos de gatitos).

DHCP o Dynamic Host Configuration Protocol (Protocolo de configuración dinámica de anfitrión/huésped), es uno de tantos protocolos de red que usamos casi todo el tiempo (sin que nos demos cuenta o lo sepamos); como HTTP, SMNP, SMTP; entre otros…

DHCP es el ente mágico que nos permite conectarnos a distintas redes sin mayor esfuerzo. Consiste en una serie de intercambio de mensajes entre un anfitrión y un huesped. En nuestras redes domésticas, el anfitrión es el módem o router que nos instala el ISP, y los huéspedes son nuestras computadoras, dispositivos móviles y electrodomésticos inteligentes.

A grandes rasgos así es como interactúa un huésped con un anfitrión; verás que es muy similar a lo que pasa cuando llegas a un hotel (sin albur):

  • HUÉSPED – ¡Hola! Quiero pertenecer a tu red.
  • ANFITRIÓN – (Revisa si hay IPs disponibles en el segmento asignado).
    • Si hay IPs disponibles:
      • ANFITRIÓN – ¡De acuerdo! Esta es tu IP, el DNS y la dirección del gateway.
      • HUÉSPED – ¡Genial! ¡Ya puedo ver gatitos!
    • Si no hay IPs disponibles:
      • ANFITRIÓN – Lo siento, pero no hay más IPs disponibles. Puedes intentarlo más tarde si lo deseas.
      • HUÉSPED – (llora).

Ya para terminar, mencionaré que un DHCP no es más que un programa de computadora: no se necesita de un dispositivo o hardware sofisticado y especializado para realizar la tarea (aunque es recomendado para redes grandes). Podemos configurar básicamente cualquier equipo de red como un DHCP y justo ese será tema de semanas siguientes. Por ahora, sólo quería dar una breve introducción; amistosa y sin detalles técnicos.

Así que me despido como siempre, deseando que el límite sea la imaginación.

Android Studio: Error “Unable to detect adb version…” al actualizar platform-tools o el IDE

Hola a todos!

Ya hemos resuelto algunos de los errores comunes que ocurren al usar Andorid Studio y el Android SDK en sus versiones más recientes en sistemas de 32 bits: es posible hacerlo sin tener que apuntar completamente a versiones previas, como hemos visto hasta ahora.

Esta semana vamos a resolver el problema de no ver nuestros dispositivos o emuladores para ejecutar una aplicación en desarrollo, o que el sistema no reconozca el ADB como un programa válido

unable-detect-adb


Esto se debe a que las nuevas versiones del ADB son programas de 64 bits y como ya he comentado en post anteriores, no es posible ejecutar estos programas en sistemas de 32 bits; por limitaciones físicas de los equipos…. Y no; instalar 2 veces el sistema operativo, no lo hace de 64 bits.

Puesto que no podemos ejecutar un programa de 64 bits por esta limitaciones, la solución es reemplazar el binario del ADB por uno de 32 bits. Podemos usar el que viene incluido con platform-tools v23.0.1, que podemos descargar a continuación:

https://dl-ssl.google.com/android/repository/platform-tools_r23.0.1-linux.zip

Descomprimimos el archivo y en el primer nivel jerárquico de directorios que contiene el ZIP, debe aparecer un archivo llamado “adb”

platform-tools

Copiamos el archivo “adb” y lo pegamos en

<android_sdk_home>/platform-tools

En este directorio ya exista un archivo llamado “adb”; debemos sobreescribirlo, pues al actualizar Android Studio o platform-tools se inserta la nueva versión de ADB; esa de 64 bits que nos da problemas, y debemos reemplazarla por esta versión de 32 bits para poderlo ejecutar.


Una vez que hayamos sobreescrito el archivo adb, Android Studio y el sistema deberían reconocer y ejecutar correctamente el ADB y deberíamos poder contactar nuestros dispositivos y emuladores Android.

correct-adb


-El límite es la imaginación-

Android: instalación en computadoras con arquitectura Intel x86 (PC)

Hola a todos!

Como quizá muchos de ustedes ya lo saben, soy un entusiasta del software/hardware libres y de los proyectos realizados bajo estas banderas. También estoy maravillado por la tecnología al rededor de los dispositivos móviles; tales como la gran variedad de sensores y las telecomunicaciones. Y seguramente también ya han notado que soy fan de una mezcla de estos dos mundos: el sistema operativo Android.

Hace un tiempo, había estado trabajando en un proyecto en el que el rendimiento y las funciones simuladas que hace el emulador del SDK; no eran suficientes para realizar las pruebas que necesitaba, así que trate de buscar una solución a mi problema.

Mientras pensaba en ello, me dí cuenta de un detalle muy obvio que hasta ese momento estaba dejando pasar desapercibido: Android es un sistema operativo. Así que me dije a mi mismo, ¿porqué no instalarlo en mi computadora en una partición nueva del disco, justo como cualquier otro SO?

Para mi alegría; descubrí que esto es mucho más fácil de lo que pensé originalmente, pues existe un proyecto que ha aprovechado el código fuente de Android; que es open source, para portarlo directamente a PC con arquitectura Intel x86 y x86_64.

Les estoy hablando del proyecto http://www.android-x86.org/ Este grupo ha lanzado varios portes de distintas versiones de Android para PC, lo cual me parece una contribución excelente al software libre y que le da muchas oportunidades a muchos usuarios.

Instalar Android en una partición independiente como SO nativo del sistema tiene algunas ventajas sobre la emulación:

  • Para empezar, el rendimiento es mucho mejor. Aún si el BIOS de tu sistema soporta virtualización por hardware, siempre se tendrá mejor rendimiento al eliminar todas las capas de abstracción posibles.
  • No necesitas instalar el Android SDK en tu sistema. Sí lo requieres sólo para el emulador, es bastante pesado y en mi opinión no es algo que valga tanto la pena sólo para emular.
  • La colección de drivers incluidos en los portes de Android para x86 es bastante buena; por lo que si tu máquina cuenta con componentes como interfaz WiFi, tarjeta gráfica; entre otros, el SO (Android) puede sacar mejor provecho de estos recursos de lo que harían otras aplicaciones como BlueStacks.
  • Puedes usar tu PC como una tablet con Android. Es decir, si tienes una laptop, ahora también puedes tener una tablet; como es mi caso. Para mi, este es un punto fuerte, ya que no soy tan fan de las tablet (pues un smartphone ofrece las mismas funcionalidades y además es teléfono) y no veo mucho sentido a adquirir una. Pero como gamer, una pantalla grande; es una pantalla grande, por lo que poder jugar los pocos juegos para móviles que encuentro atractivos en una pantalla grande (pudiendo incluso utilizar un monitor externo a través del puerto S-VGA [sí, mi portátil aún usa S-VGA y módem ¿algún problema?]) me parece genial. Ya sé que en este caso, las Phablets son una alternativa; pero creo que el móvil que estoy usando aún tiene bastante vida útil por delante como para jubilarlo por un simple capricho… Y tiene un tamaño razonable para ser un teléfono…
  • Otra ventaja basada en el punto anterior: si tienes una computadora vieja por allí arrumbada y sin propósito en la existencia, puedes darle una vida nueva como dispositivo Android… O instalarle Windows XP o 95 para jugar algunos clásicos.

Así es que si tú como yo, encuentras útil contar con un sistema con Android instalado en una máquina; a continuación les explico cómo hacerlo.


Comencemos por descargar la versión de Android que queremos tener. Para ello, vamos a http://www.android-x86.org/download y seleccionamos la versión de Android que deseamos. Además de la variedad de versiones de Android, disponibles, también hay algunas versiones de CyanogenMod disponibles para quienes lo prefieran.

Tal vez notes que la versión que quieres descargar se presenta en varias opciones:

  • x86 (32 bit) – Elige esta opción si tu procesador es de 32 bits. Un procesador de 64 bits también puede ejecutar esta versión, pero mejor aprovechalo al máximo.
  • x86_64 (64 bits) – Elige esta opción SOLO si tu procesador es de 64 bits. No es posible ejecutar un programa compilado para 64 bits en un sistema de 32.
  • Legacy – Elige esta opción si el BIOS de tu sistema es (o soporta) Legacy (antiguo – viejo). Normalmente lo sabes si al encender la máquina puedes ver la pantalla del BIOS y si al presionar teclas como F2 o F8 antes de que comience a cargar el SO tienes acceso a la configuración del mismo.
  • EFI – Elige esta opción si el BIOS de tu sistema es reciente. Normalmente usas un BIOS EFI si al encender tu máquina pasas de apagado a “cargando Windows” sin ver un cursor parpadeando ni letras blancas que con alguna descripción de tu sistema.
  • Live – Elige esta versión si en lugar de instalar Android en el sistema sólo quieres ejecutarlo desde un CD o una USB sin instalarlo. La desventaja de hacer esto es que cualquier cambio que hagas puede perderse (sobre todo su ejecutas en vivo desde disco), por lo que cualquier configuración o app que instales se perderá siempre que apagues el sistema.
  • ISO Image – Elige esta opción si vas a quemar la imagen en un CD o DVD. Estas imágenes también puedes “quemarlas” en una USB.
  • USB Image – Elige esta opción si vas a “quemar” la imagen en una USB.

Una vez que hayas descargado la versión de Android de tu elección, ahora hay que quemarla. Si vas a instalar desde CD o DVD, simplemente usa tu programa quemador preferido (el quemador por defecto de Windows, Roxio, Burner…) Si vas a instalar desde una USB, puedes usar UNetbootin desde Windows, Mac y Linux, Win32 Disk Imager en Windows; o desde sistemas basados en Debian hacer:

# cp ruta/a/la/imagen/descargada /dev/sdX
# sync

Recuerda reemplazar la “X” en “sdX” por la letra que tenga asignado el directorio donde se ha montado la USB en la que quieres quemar la imagen.


Ahora vamos a crear una partición para Android. Este procedimiento es el mismo que seguirías para instalar Linux o cualquier otro SO en un sistema multiboot; por lo que he escrito una entrada independiente para este paso.

Android x86 soporta las particiones en formato NTFS, FAT32, EXT2 y EXT3, pero no puede escribir nada en particiones FAT32; por lo que es poco recomendado. En mi opinión, usar una partición EXT3 sería lo mejor, aunque no le veo nada de malo a usar EXT2 o NTFS. También soporta que el SO coexista con otro en la misma partición, pero a mi gusto esto es bastante sucio y es preferible dedicarle su propio espacio.

Puedes saltarte este procedimiento y pasar al siguiente párrafo si prefieres que Android sea el único SO del sistema; pues el instalador puede formatear automáticamente la partición del disco que le indiques, si no la formateas, entonces el SO coexistirá con la información que ya esté en la partición; incluyendo coexistir con otro SO (pero ya di mi opinión al respecto).

Varios usuarios reportan que usando particiones de desde 5Gb se obtienen buenos resultados; pero en mi opinión, recomendaría usar entre 16 y 32 Gb que es lo que usualmente traen los dispositivos con Android.

Da clic aquí para abrir el tutorial sobre cómo gestionar particiones usando GParted con Debian Live.

Bien, ahora que tenemos una partición, podemos continuar con la instalación.


Previamente a iniciar la instalación debes insertar el medio en el que has quemado la imagen de Android (el disco o la USB). Enciende la máquina y asegúrate de arrancar desde el medio correcto (disco o USB); para esto puede que necesites revisar las opciones de arranque de tu BIOS.

Una vez que arranques desde el medio con la imagen, te aparecerá un menú muy simple en modo texto. Elige la opción “Install Android to harddisk“.

menu

Ahora debes elegir la partición en la que quieres instalar Android. Si deseas reformatear, selecciona la opción con el sistema de archivos que deseas usar. Recuerda que esto borrará todo lo que haya en la partición, así que asegúrate de no estar perdiendo nada importante. Si ya habías formateado la partición o conservar la información que haya (esta es la opción que eliges para hacer coexistir Android con otro SO), escoge “Do not format“.

partition

ext3

A continuación, el instalador preguntará si deseas instalar GRUB. Si ya cuentas con un sistema multiboot; elige que NO, ya que podrías sobreescribir el cargador que hayas configurado previamente. Si tu sistema aún no es multiboot o Android será el único SO de tu equipo, elige que SÍ.

grub

Después de esto sólo nos quedará esperar a que los archivos sean descomprimidos y copiados en la partición indicada y ¡listo!


Si al reiniciar tu sistema GRUB o tu cargador de arranque no muestra a Android o algún otro de los SO que tengas instalado, puedes consultar el tutorial que he hecho para reconfigurar GRUB.


¡Uf! Puede que parezca un poco tedioso, pero vale la pena y es bastante divertido contar con una “tablet” adicional. Puedes dar de alta una cuenta de Google para usar la Google Play como en cualquier otro dispositivo e instalar apps tal y como lo harías en cualquier teléfono o tablet con Android, ¡genial no?

FB_IMG_1491502299797

FB_IMG_1491502270741


Antes de terminar, quiero aclarar que las instrucciones aquí las he probado y me han funcionado bien. No puedo responsabilizarme si algo sale mal y no puedes arrancar ningún SO, pierdes información o se daña el equipo con el que hayas intentado seguir los pasos…


En fin, espero le sea de utilidad a más de uno y que el límite sea la imaginación.

Cómo gestionar particiones usando GParted con Debian Live

Hola a todos!

Estoy redactando una entrada donde explico cómo instalar un particular SO en una PC, pero en el proceso invito a crear sistemas multiboot; es decir, tener varios sistemas operativos instalados en una misma máquina y poder elegir el deseado al arranque.

Para ello, creí importante crear un post independiente para explicar cómo gestionar particiones en el disco; por lo que estamos aquí. Si tienes curiosidad sobre los sistemas de archivos, te invito a leer el post que he escrito al respecto.

Bien; sin más, comencemos.


Es sumamente importante antes de empezar, realizar un respaldo de toda la información en disco, ya que siempre existe; por diminuto que sea, el riesgo de que algo salga mal durante el procedimiento. En lo personal, he realizado este procedimiento varias veces y nunca he perdido nada realmente; he desconfigurado los cargadores de arranque, pero eso tiene solución.

No me hago responsable por la pérdida de información, programas o Sistemas Operativos o daños en el sistema que puedan ocurrir…. Aunque insisto, he hecho esto varias veces y nunca he tenido mayores problemas.


Primero debemos empezar por contar un un SO en vivo. Hasta el disco de instalación de Windows cuenta con un gestionador de particiones, pero a mi gusto es bastante limitado, por lo que usaré Debian Live; que trae preinstalado GParted, una aplicación para gestionar particiones que a mi gusto es bastante simple y buena. Si no quieres usar Debian Live, puedes optar por cualquier otra distribución de Linux que cuente con GParted u otro gestionador de particiones.

Para descargar Debian Live, vamos a la página de descargas de Debian y elegimos la versión deseada (amd64 para PC de 64 bits o i386 para PC de 32 bits) de Debian Live: https://www.debian.org/CD/live/


Una vez que hemos descargado la imagen del SO en vivo, procedemos a quemarla en un medio adecuado. Las imágenes de Debian Live pueden escribirse indiferentemente un un disco (CD, DVD) o en una memoria USB.

Para quemar un CD, DVD usamos el quemador de nuestra preferencia (por ejemplo el quemador por defecto de Windows, Roxio, Burner, etc…).

Para “quemar” una USB, podemos usar herramientas como Win32 Disk Imager, o desde la consola de un sistema Debian hacer:

# cp ruta/a/la/imagen/descargada /dev/sdX

# sync

Es importante recordar que debemos cambiar la X por la letra que le haya asignado el SO a la unidad de USB en la que queremos grabar la imagen.


Ya que tenemos un medio apropiado con la imagen quemada, lo siguiente será insertar el medio en la máquina con el disco duro donde queremos administrar las particiones. Apagamos la máquina si estaba encendida (que podríamos necesitar; por ejemplo, para insertar el disco primero).

Lo siguiente depende del BIOS; ya que si es “legacy”, mostrará al arranque opciones para seleccionar el medio de inicio deseado. Normalmente esto se hace presionando F2, F8, F10 u F12 al arranque; pero debes verificarlo en tu modelo de PC.

Los BIOS EFI pueden ser un poco más problemáticos en este sentido, por lo que te recomiendo buscar un tutorial específico para tu modelo de PC y versión de BIOS para arrancar desde el medio indicado (el disco o la USB).


Cundo el sistema inicie desde el medio correcto, deberemos ver una pantalla como la siguiente:

menu-d

Podemos iniciar usando la primer opción. Después de un rato (sobre todo usando un disco, esto puede tomar algunos minutos), deberías ver cargado el escritorio del sistema. Si después de varios intentos no logras iniciar adecuadamente, puedes intentar con las opción 686-pae (la tercera). Si no puedes cargar la interfaz gráfica; no podrás usar GParted para administrar las particiones, pero aún podrías hacerlo con programas en modo texto en la consola del sistema.


Una vez que ha cargado el escritorio, abrimos “Gparted” desde el menú de aplicaciones.

Cuando inicie GParted, deberás ver una ventana como esta:

gparted

El diagrama en la parte superior de la ventana, representa la unidad seleccionada. Cada división rectangular de colores es una partición. El relleno amarillo dentro de cada rectángulo representa el espacio ocupado en cada partición. El candado representa que la partición está montada; y puesto que no debemos intentar modificar particiones montadas, no nos permitirá modificarlas a menos que sean desmontadas.

Lo anterior es una razón importante del por que la administración de particiones debe hacerse en vivo y no durante la ejecución de algún SO en alguna de las particiones, pues no podemodeberíamos desmontar la partición del SO; y si es una distribución de Linux, tampoco podemos desmontar la partición del área de intercambio.

Con esto dicho, elegimos el disco al que le queremos modificar las particiones. Para esto podemos desplegar la lista que aparece al hacer clic en el botón que indica la unidad que se está desplegando actualmente; en mi caso /dev/sda.


Supongamos que queremos crear una nueva partición para instalar un nuevo SO. Recuerda que un disco sólo puede tener 4 particiones “físicas” a la vez, por lo que si requieres hacer más de 4 particiones por alguna razón; una de las 4 particiones físicas deberá servir como anfitrión de particiones virtuales. No hay mayor diferencia entre una partición real y una virtual para el SO o los datos que contenga la partición, por lo que esto no representa ningún inconveniente.

Será muy raro que el disco contenga de entrada “espacio sin asignar” suficiente como para alojara un SO. Como podrá ver en la imagen anterior, en mi caso hay 1MB entre mi partición con Windows y la partición con Debian. En mi caso, este espacio ha quedado para siempre sin uso por las características de las particiones que tengo; es posible que al particionar te quede un espacio diminuto similar sin uso entre particiones, no te angusties y déjalo pasar; es sólo 1MB.

Así que, vamos a crear un espacio suficiente como para alojar un SO. Para ello, seleccionamos una partición que tenga suficiente espacio libre (en blanco y no en amarillo) para hacerla pequeña y alojar en ese espacio nuestro nuevo SO. Para ejemplificar, voy a simular que hago pequeña la partición de Windows.

Para esto, damos clic derecho sobre la partición que queremos hacer pequeña y del menú emergente seleccionamos “->| redimencionar/mover”. Aparecerá un cuadro de diálogo como el siguiente:

gparted1


Ahora, ya sea que prefieras usar el slider o ingresar el valor exacto en MB del tamaño de la partición que quieres, puedes hacerlo aquí para crear el espacio vacío para el nuevo SO.

Si quieres ser muy preciso en el tamaño de GB que quieres para el SO, recuerda que 1GB = 1024 MB. Si no te interesa tanto la precisión, simplemente usa 1GB ~ 1000MB y multiplica 1024 o 1000 por el número de GB que quieres dejar para el nuevo SO.

Nota que puedes abrir el espacio para el SO al principio o al final de la partición. En general, es indiferente donde hagas el espacio, incluso esto es conviene; por ejemplo, yo puedo decrementar tanto la partición con Windows como la que tiene Debian en tamaño para tener un espacio suficientemente grande para otro SO; para ello, decrementaría la partición con Windows al final y la partición con Debian al inicio. Las particiones deben ser contiguas: no puedes usar huecos por todo el disco como una sola partición.

También podemos mover una partición hacia los lados si tiene espacio libre para hacerlo. Esto también es bastante útil, ya que por ejemplo; podría también reducir la partición del área de intercambio de Linux para tener más espacio para una nueva partición. Pero como las particiones no pueden ser discontinuas, entonces puedo mover todas las particiones para agrupar todo el espacio libre en un sólo bloque.

No tenemos que preocuparnos por los archivos contenidos en la partición a la hora de moverla, ya que GParted automáticamente se encargará de mover los archivos adecuadamente.

El detalle de reducir una partición con un SO desde la izquierda o moverla;  es que puedes provocar que el SO no inicie, ya que el programa cargador tiene una referencia a la primer dirección de memoria en disco del SO; por lo que al mover la partición o al menos su inicio, movemos los archivos del SO y la referencia que tenga el cargador de inicio ya no será válida y marcará un error al tratar de cargar el SO.

Por esto; si necesitas mover particiones o recortarlas desde el inicio (desde la izquierda) es muy recomendable que al final de este tutorial sigas alguno de estos también si te resulta de utilidad:

Cómo reparar el cargador de inicio cuando hemos movido Windows de su lugar.

Cómo reparar GRUB o identificar SO nuevos y agregarlos al menú de arranque.


Así, al recortar y mover particiones tendremos un nuevo espacio “no asignado” listo para ser formateado. Cabe aclarar que los cambios que hayas realizado hasta este punto no surtirán ningún efecto real en el sistema hasta que presiones el botón “Aplicar”; y aún cuando lo hagas GParted te pedirá que confirmes las acciones pues podrían destruir la información contenida en el disco (por ejemplo al borrar una partición, hacerla más pequeña que lo que ocupan los archivos ya almacenados en ella, etc). Verás algo como esto en la ventana de GParted:

gparted2


Ahora vamos a aprovechar este espacio vacío para crear una partición. Para esto, damos clic derecho sobre el rectángulo gris. Del menú emergente, elegimos “nueva”.

En este punto es necesario aclarar que si tienes 4 particiones; como en mi caso, GParted no podrá crear una nueva partición, pues 4 particiones es el límite físico para crear particiones. Para crear nuevas particiones debemos primero crear particiones lógicas.

Para crear una partición lógica debemos sobreescribir el contenido de una partición existente, por lo que elige bien y respalda archivos antes de continuar.

Si tienes menos de 4 particiones puedes continuar a la siguiente sección omitiendo este punto. Para crear una partición lógica; como he comentado, debemos comenzar por formatear una de las 4 particiones físicas existentes.

Damos clic derecho sobre la partición que queremos que aloje la particiones lógicas y del menú emergente elegimos “formatear cómo” y luego “extendida”. Si no aparece la opción para formatear la partición como extendida debes intenta lo siguiente:

  • Si tienes espacios no asignados, comprueba que ninguno de ellos sea una partición extendida.
  • Desmonta el la partición del área de intercambio.
  • Trata de dejar un espacio de 1MB de espacio no asignado entre particiones.

Usualmente la partición de área de intercambio se trata como a una partición extendida, por lo que es conveniente formatearla directamente como “extendida” en lugar de “linux-swap”. Si usas un SO basado en Linux (excepto Android hasta donde sé), forzosamente necesitas el área de intercambio, por lo que posteriormente deberás crear una nueva dentro de la partición extendida. Lo anterior es importante ya que no es posible contar con más de una partición extendida.

gparted3

Ahora cuentas con una partición extendida. Es sobre esta partición que puedes escribir tantas particiones lógicas como desees.


Para crear una partición en espacio no asignado, hacemos los siguiente:

Damos clic derecho sobre un espacio “sin asignar” y del menú emergente, elegimos “nueva”. Se abrirá el cuadro de diálogo para modificar una partición. En él, ingresamos el tamaño deseado en MB, el sistema de archivos y la etiqueta de la partición si lo deseamos también.

gparted4

Si queremos crear una partición lógica en una partición extendida, el procedimiento es el mismo que el anterior, pero en lugar de seleccionar y dar clic derecho sobre un espacio “sin asignar”, escogerías la partición extendida.

Al final damos clic en “añadir” y veremos la nueva partición indicada en el diagrama del dispositivo.

gparted5


Los cambios que hemos hecho hasta ahora son virtuales; no tendrán efecto hasta de que demos clic en el botón con una paloma verde y grande “aplicar”. Entonces recibiremos una advertencia de que podríamos estar perdiendo información y que los cambios son irreversibles. Si estás seguro de lo que estás haciendo, da clic en aceptar y espera a que GParted termine de formatear tu dispositivo de almacenamiento.


Reitero que si has modificado una partición que contiene Windows podrías necesitar reconfigurar el cargador de Windows usando el disco de instalación. Si has modificado particiones con un SO, podrías necesitar reconfigurar o instalar un cargador de arranque como GRUB. Cualquier sea el caso, podrías encontrar útiles los siguientes post:

Cómo reparar el cargador de inicio cuando hemos movido Windows de su lugar.

Cómo reparar GRUB o identificar SO nuevos y agregarlos al menú de arranque.


Ahora tienes una nueva partición lista en la que puedes almacenar tu información o instalar un SO. La etiqueta de las particiones (por ejemplo, si tenemos sda1, sda2, sda3), serán las mismas siempre que veas el dispositivo; incluso con SO diferentes y corresponden a su orden de creación (sda1 fue la primer partición escrita en el medio, sda2 la segunda y sda3 la última).

Lo anterior es útil porque puedes recordar la etiqueta de la partición que acabas de crear e indicarla al instalar tu nuevo SO y evitar sobrescribir el SO en una partición ya ocupada… Lo cual no debe ser muy lindo.

En fin, espero más de uno encuentre utilidad en esto. Que el límite sea la imaginación… Y la arquitectura de la interfaz SATA conectada al HDD.

¿Discos Duros o de Estado Sólido? ¿Sistema de archivos? ¿Qué son?

Hola a todos!

Espero no desbordar el stack de ejecución; pero escribiendo un post sobre instalación de sistemas operativos multiboot, me di cuenta que necesitaba un post sobre cómo gestionar particiones y me di cuenta que sería buena idea escribir un post sobre las diferencias entre los tipos de Discos Duros y qué es un Sistema de Archivos. Así que comencemos.

StackOverflowError

Caused by: TooManyPostsDependenciesError


Discos Duros

El disco duro; en cualquiera de sus presentaciones, es la unidad de almacenamiento por defecto hoy en día. Digo en cualquiera de sus presentaciones porque seguramente ha notado que hay al menos dos tipos: los “normales” y los de estado sólido.

Los “normales” son los verdaderos y auténticos discos duros que han estado con nosotros desde casi siempre. De hecho; se les dice así (disco duro) porqué si uno abre la caja a la que llamamos “el disco duro”; encontraremos uno o más platos de metal bastante rígidos en su interior, acompañados por una cabeza lectora similar a la de una tornamesa (¿todavía hay tornamesas por el mundo?): literalmente son discos duros.

hdd

Si abriéramos un “disco duro” de estado sólido, encontraríamos varios chips y tarjetas… Y ningún disco a la vista capitán… Es muy similar a lo que encontramos dentro de una memoria flash USB.

InsideanSSD.jpg

Se les dice discos duros por costumbre, pero no son discos en ningún sentido (bueno, no he visto que los fabriquen con forma redonda). La computación tiene problemas de nomenclatura en varias áreas…

Los discos duros “normales” son más lentos que los de estado sólido por el mecanismo de lectura y escritura que es muy diferente en ambos:

  • Los “normales” requieren girar los discos duros mientras la aguja escribe o lee puntos magnéticos en la superficie de los discos. Las piezas mecánicas toman tiempo en comenzar a girar, ya que el dispositivo debe rotar a una velocidad constante para leer y escribir: las operaciones no pueden realizarse mientras los discos aceleran. Además, la cabeza también es una pieza mecánica y le toma tiempo moverse sobre los discos. Tampoco puede operar mientras ella misma en movimiento.
  • Los de estado sólido, funcionan muy similar a una RAM: mediante señales eléctricas direccionan memoria y en unos cuantos ciclos de reloj escriben o leen un paquete de datos en una dirección de memoria sin hacer más. Al prescindir de piezas mecánicas; incluso los “discos duros” de estado sólido más lentos y económicos suelen ser mucho más rápidos que los mejores discos duros “normales”.

Además, los discos duros “normales” son extremadamente delicados: son muy susceptibles a las vibraciones, por lo que llevar un disco duro en la guantera del auto o dejarlo caer desde una altura mínima, puede ser fatal para el mismo; pues las piezas mecánicas pueden moverse de su lugar o la cabeza puede golpear los discos arruinando la información de uno o varios sectores (más adelante explicaré qué es un sector).

Los “discos duros” de estado sólido son más confiables, pues hay que darles un buen golpe para desoldar los chips y buses de la tarjeta.

…Y lo digo por experiencia: un “disco” de estado sólido (y un buen mantenimiento) hace la diferencia entre que una máquina de 10 años se comporte como una máquina de 10 años o ponga batalla contra las máquinas actuales.

Pero; pese a todas estas diferencias, el objetivo de ambos medios de almacenamiento es exactamente el mismo: almacenar mucha información de forma persistente.

Entonces, los HDD (Hard Drive Disk o Unidad de Disco Duro) y los SSD (Solid State Disk o Disco de Estado Sólido) almacenan o leen datos dependiendo de sus mecanismos de información pero… ¿y luego? Bien, seguramente has escuchado alguna vez el término “sistema de archivos”, como lo son “FAT”, “NTFS”, “EXT”; entre otros, y si no; no te preocupes que para eso es este post.


Sistema de archivos

Sabemos que podemos guardar el archivo “hola.txt” y “Guau.java” en el disco… Pero… Si guardamos “hola.txt” primero, ¿dónde guardamos “Guau.java” de forma que no se encime sobre “hola.txt”? ¿cómo representamos el nombre del archivo?  Y si seguimos guardando archivos… ¿cuantos y de qué tamaño había antes del que quiero leer para poderlo leer desde su inicio; su primer dirección de memoria, y no leer partes de otros archivos previos o empezar a leerlo por la mitad?

El sistema de archivos son básicamente meta-datos en el HDD; y esa meta-información nos permite resolver todos los problemas que tendríamos de no usar un sistema de archivos. El sistema de archivos describe un formato (de allí que se formateen los discos. No, formatear no significa instalar o reinstalar Windows. Y formatear no es la única forma de reparar Windows; en sentido estricto, eso ni siquiera es reparar…)

El formato divide el disco en “partes” de forma que los archivos se agrupen en esas “partes” del disco. Formalmente, a estas “partes” se les conoce como sectores. Así, es más fácil para el mecanismo de lectura y escritura localizar un archivo por el sector en el que vive. Es similar al cómo las ciudades se dividen en códigos postales; ¿te imaginas tener que entregar una carta en una ciudad de un millón de habitantes -o muchísimos más- sin tener idea de por donde empezar?

Esta es una de las razones por las que en tiempos remotos, los discos flexibles escritos en una Mac no se podían leer en una PC: los sectores del disco se disponen de forma diferente en los formatos que trabajan y sólo usando un driver o dispositivo especial podríamos hacerlo.

A su vez, los sectores se dividen en bloques de memoria que alojarán parte de un archivo. Estas serán las unidades de almacenamiento que usará el sistema de archivos. Puesto que son la unidad de almacenamiento, si un archivo usa menos unidades reales de las que abstrae el sistema de archivos, ese espacio real sobrante no podrá ser utilizado por ningún otro archivo y desgraciadamente será espacio despreciado en disco… Unas por otras, ¿no?

Un ejemplo de lo anterior, si un archivo sólo es de 13 bits, pero el sistema de archivos divido cada sector en bloques de 8bits (1 byte), entonces tendrá que usar el número de bloques mínimo indispensable para alojar 13bits: 2 bloques; es decir, el archivo ocupará en disco 16bits (2 bytes) en lugar de 13. Los 3 bits sobrantes serán desperdiciados, pues nadie más podrá usarlos.

Y finalmente, la cereza del pastel en el sistema de archivos es la tabla de innodos. Un innodo es un objeto (cosa pues) que describe un archivo: cómo se llama, cuando fue creado, quién es el dueño, a qué grupo de usuarios pertenece, cuándo fue modificado, quién lo modificó por última vez, en qué sector vive, en qué bloque empieza y qué tamaño tiene (para poder leerlo completamente); y puede describir otras cosas de los archivos.

El tamaño de un innodo restringe el tamaño que puede tener un archivo en disco. Por ejemplo, si el sistema de archivos es de 32 bits (te estoy viendo FAT32), no es posible guardar archivos que sean de más de 4GB; pues un entero de 32 bits a lo mucho puede representar 4GB. Por eso me gusta formatear mis memorias USB a NTFS.

La tabla de innodos, no es más que la colección de todos los innodos. El tamaño de la tabla depende del sistema de archivos en cuestión y es posible acabarnos los innodos aún cuando el disco no está lleno (lo cual a estas alturas del partido es muy poco común) y no es posible modificar la tabla de innodos para agregar más: ese espacio será desperdiciado como en los bloques.

La tabla de innodos vive en el disco también; junto con los archivos. Y es la tabla de innodos (y a veces otros descriptores) la que ocupa un cierto espacio en disco de forma inicial, por lo que al formatear un disco JAMÁS podremos usar el 100% de su capacidad física y el Sistema Operativo nos informará que el disco tiene una capacidad menor a la que anuncia el vendedor.

Para más información respecto a lo tratado en esta parte del post, les recomiendo ampliamente el siguiente excelente vídeo de Computerphile:


Espero que esto les sea de utilidad y que les ayude a entender un poco mejor las diferencias y equivalencias entre los HDD y los SSD y porqué los sistemas de archivos son importantes.

Que el límite sea la imaginación. Y el tamaño de la tabla de innodos… Y el tamaño de los bloques en cada sector… Y el contador del tamaño de archivo en cada innodo…