Redes TCP/IP (parte 3)

En este artículo voy a intentar describir de una forma muy simple cómo es la comunicación en una red TCP/IP, pero antes quisiera aclarar que esta descripción no pretende ser un documento técnico, de hecho, pretende ser sólo un resumen en el que describo los aspectos que, a mi juicio, son los más relevantes.

Vamos a utilizar la siguiente red para mostrar cómo se comunica el equipo con IP 192.168.1.101 con los demás equipos.

De acuerdo al diagrama podemos resumir que vamos a analizar 3 tipos de acceso:

• A la 192.168.1.102 en la misma LAN
• A la 192.168.5.101 en otra LAN (posiblemente en el mismo edificio)
• A un equipo en Internet donde yyy.yyy.yyy.yyy puede ser cualquier dirección válida en Internet

Comunicación en una red local

Cualquier dato que sea transmitido a través en una interfaz de red empleará tramas (generalmente 802.3 ó compatibles) que contienen (entre otros datos) la dirección MAC origen y la MAC destino, por lo que cualquier intercambio de datos se hará siempre entre dispositivos en la misma LAN.

En nuestro equipo tenemos configurada una IP, la 192.168.1.101 y (para este ejemplo) tenemos configurada la máscara 255.255.255.0, por lo cual, la 192.168.1.102 pertenece a la misma LAN, es decir, es local.

A continuación, el protocolo procede a indagar a qué MAC corresponde la 192.168.1.102, primero consulta en su tabla de direcciones locales llamada tabla ARP si ya esta asociada la IP a una MAC, si es así utiliza esta MAC para transmitir, si no, lo averigua utilizando tramas con la MAC destino FF:FF:FF:FF:FF:FF (esta dirección en realidad representa a todos los dispositivos de la red local, por lo que todos reciben las tramas y las procesan según sea el caso) esperando que algún dispositivo se reporte con esa IP.

Teniendo ya la MAC asociada a la IP, el protocolo transmite empleando tramas con esa dirección física como destino.

Debido a que esta comunicación únicamente va de interfaz a switch y de switch a interfaz y es el mismo protocolo es que se encarga de hacer la "conversión" de IP a MAC, el switch sólo se encarga de transmitir las tramas al dispositivo que corresponde. Es por esto que se dice que el switch es un dispositivo de capa 2 (aunque en realidad ya existen switches que hacen más que eso).

Comunicación en red extendida

Para la comunicación con la 192.168.5.101, de acuerdo con la máscara, se encuentra fuera de nuestra LAN, es decir, es remota.

Para comunicarnos con una IP externa es necesario tener definido un ruteador, normalmente tenemos definido uno solo al que denominamos el default gateway ó default router, en este ejemplo el que tenemos definido en este equipo es el 192.168.1.1

Observen que esa IP es local para la 192.168.1.101 y, como comenté anteriormente, la comunicación siempre es utilizando dispositivos locales, por lo  que, todos los paquetes que vayan dirigidos a IP's remotas serán enviados a la IP del ruteador. Es por esta razón que se dice que un ruteador es un dispositivo de capa 3.

En nuestro ejemplo, el ruteador tiene una interfaz en la red 192.168.1.0/24 y otra en la red 192.168.5.0/24, por lo que "pasa" el paquete de una interfaz a otra y desde la 192.168.5.1 hace el envío a la 192.168.5.101

Por supuesto que en la vida real, en una organización difícilmente hay un solo ruteador, lo más probable es que tenga varios y que éstos estén interconectados entre sí por medio de switches o de otros ruteadores, por lo que en la configuración de los ruteadores hay listas que indican dónde localizar una red u otra, estas listas se llaman tablas de ruteo.

La definición del default router nuestros equipos (que, normalmente se les llaman hosts) no solo nos permite transmitir a redes remotas, si no que, además, nos permite recibir paquetes remotos. Esto es debido a que sólo recibe paquetes que provienen de redes remotas de IP's definidas como ruteadores. Las IP's que son definidas así se encuentran en su tabla de ruteo y si, efectivamente, es igual a las tablas de ruteo que se encuentran en los ruteadores. De hecho, al menos en teoría, cualquier host podría ser capaz de ser un ruteador, siempre y cuando tenga las suficientes interfaces de red.

Comunicación de redes privadas a Internet

Por supuesto que en toda organización actual el acceso a Internet es indispensable, como comenté en artículos anteriores, la redes privadas no pueden accesar directamente a Internet, por lo que es necesario un dispositivo que haga la "conversión" de las peticiones que provienen de IP's de la red privada a una IP pública que, en este caso, denominé como xxx.xxx.xxx.xxx (la cual, puede ser cualquier dirección válida proporcionada por nuestro proveedor de Internet). A esta "conversión" se le llama traducción de dirección de red (NAT) y el dispositivo encargado de ésta se llama firewall.

Además de permitir el uso de una NAT para las peticiones de salida de la red privada, es posible el asociar una IP pública a un host dentro de la red privada, además de poseer filtros para permitir el acceso de un lado a otro de solo unos servicios. Por ejemplo, es posible tener un servidor web dentro de nuestra red privada y por medio del firewall definir una NAT que traduzca las peticiones a una IP pública hacia la IP privada del servidor bloqueando cualquier petición que no sea al servicio web (ftp, por decir alguno).

En organizaciones reales es frecuente encontrar definidas por medio de firewalls varias "zonas" que, normalmente, son de tres tipos: zona privada en la que se encuentran usuarios y servidores con aplicaciones propias de la organización; zona desmilitarizada (DMZ) en la que se encuentran los servidores a los que se requiere tenga acceso personas externas, y la zona pública que, prácticamente, es lo que se encuentra fuera de la organización.

Ya que los bloqueos o filtros se pueden hacer a nivel servicio, se dice que el firewall es un dispositivo de capa 4, sin embargo, en la actualidad hay firewalls que permiten monitorear y analizar si las peticiones a ciertos servicios tratan de hallar una vulnerabilidad haciendo una serie de peticiones inválidas, este tipo de firewall es un dispositivo de capa 7.

Con esto doy por terminado el tema, espero les sea de utilidad y si alguien tiene algún comentario, por favor, no duden en compartirlo.

Redes TCP/IP (parte 2)

Continuando con el tema de redes TCP/IP vamos a profundizar un poco más en lo que corresponde al direccionamiento IP.

El hecho de que las direcciones IP son números jerárquicos e independientes de las direcciones físicas debería ser una razón más que suficiente para que este protocolo tuviera el éxito que tuvo, sin embargo, en realidad su éxito se debió solo a que la Internet está basada en este protocolo.  Una prueba de ello es que en Windows el driver TCP/IP estuvo disponible de forma nativa hasta la versión 95, antes de esa versión era necesario adquirir un software adicional generalmente llamado winsock, además de que el NetBIOS solo podía ser utilizado con el NetBEUI en forma local y con el IPX/SPX para redes extendidas.

Direcciones IP

Las direcciones IP en realidad son números de 32 bits lo cual, en teoría, nos da la capacidad de 2 a la 32 direcciones, es decir, 4,294,967,296 posibles direcciones. Este número binario de 32 posiciones se divide en 4 grupos de 8 posiciones, a cada uno de estos grupos se le llama octeto y regularmente se representa a cada uno con su equivalente decimal y se delimitan por puntos, como ejemplo, vamos a ver la representación de la IP 192.168.1.100:

Cada dirección IP además de darle un número único a cada componente también nos indica a que red pertenece. Como recordarán en el artículo anterior, una red es en realidad una red de redes, cada una de estas "pequeñas redes" se le denomina red de área local (LAN). Imaginemos que una dirección IP es como el nombre de una persona su apellido indica a qué familia pertenece, en este caso, los primeros números de la IP indican a que LAN pertenece, sin embargo, así como en la vida real hay apellidos largos, también los hay en las direcciones IP, por lo que se utiliza una "clave" que nos indica de que "tamaño es el apellido". Esta clave se le llama máscara de subred (subnet mask) y se le llama así porque "rellena" con números 1 la parte que representa el número de red y con números 0 la que representa al número de nodo (recuerden que son números de 32 bits), en este ejemplo vamos a decir que los primeros 24 bits representan a la red y el resto al nodo:

Al igual que las direcciones IP las máscaras se representan también con su decimal, por lo que la máscara queda como 255.255.255.0 y la red queda definida como las posibles direcciones que hay desde la IP 192.168.1.0 hasta la 192.168.1.255

Por una condición de protocolo, la primera dirección IP de una LAN queda reservada como el número de red por lo que en nuestro ejemplo la red es la 192.168.1.0 por lo que una manera muy común y adecuada de representarla es con el número de red y su máscara de esta forma: 192.168.1.0/255.255.255.0

También existe la condición de reservar a un número que represente a todos los nodos de una LAN, un número común a todos, al cual se le llama broadcast y, generalmente, se utiliza el número de la última dirección posible, en este caso el 192.168.1.255

Actualmente se emplea una forma más corta para representar a las redes, con el número de red (o sea, su primer nodo) y el número de 1's de su máscara (en este ejemplo 24) de esta forma: 192.168.1.0/24

Del porqué definir una máscara grande o pequeña, depende de la necesidad que tengamos de más redes pequeñas o menos pero grandes. Por ejemplo, si definimos una red con máscara 24, quiere decir que tenemos 8 bits para direcciones locales, es decir, 2 a la 8 que es igual a 256, si usamos una máscara de 28, entonces tendríamos disponibles 4 bits, o sea, 2 a la 4 que es igual a 16 y se representaría como 255.255.255.240, esto es porque los primeros tres octetos son ocho números 1 (11111111) que en binario representan 255 decimal y el último octeto son cuatro 1's y cuatro 0's (11110000) que en decimal es 240

Comúnmente, la redes que son definidas de 8 bits son llamadas de Clase A, de 16 bits Clase B y de 24 Clase C, sin embargo, esta forma de definir redes no es obligatoria, por lo que no es de extrañar el encontrar redes definidas con máscaras mas "exóticas".

Segmentación

También es una práctica común que a una red ya definida la dividamos en redes aún más pequeñas. Por ejemplo, supongamos que tuviéramos la necesidad de dividir en dos nuestra red 192.168.1.0/24 la podemos segmentar con un bit más quedando dos redes de 128 nodos así: 

También podría segmentarse en 4 redes de 64 nodos cada uno con 26 bits y quedarían como: 192.168.1.0/26, 192.168.1.64/26, 192.168.1.128/26 y 192.168.1.192/26. La máscara para las 4 sería 255.255.255.192

Redes reservadas

Debido a que el número de IP's en Internet es limitado, existen 3 redes que se encuentran reservadas para uso interno, esto quiere decir, que la empresa u organización a la que pertenecemos puede usar cualquiera de éstas dentro de su red local según sea su necesidad con la seguridad de que nadie en la red pública la va a utilizar y para "salir a Internet" podrá utilizar uno o varios firewall que se encarguen de hacer la traducción a una IP pública (NAT). Pero, ¿por qué es importante esto?. Supongamos que erróneamente usamos la 172.0.0.0/16 y desde algún nodo necesitamos accesar a un sitio de Internet con la IP 172.0.10.27 (Nota: en realidad no sé si existe tal sitio pero la IP si es válida para ser pública), en ese caso la petición no va a llegar al firewall ya que el equipo de ruteo supondrá que esa IP se encuentra dentro de la red local. Para este ejemplo, lo más probable es que no habría mayor problema que el no poder accesar a alguna página de Internet, pero, si fuera el caso de que ese acceso fuera muy importante, entonces nos encontraríamos en la necesidad de tener que definir nuevamente nuestra red interna.

Las redes reservadas para uso interno son:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Finalmente (y no menos importante) existe otra red reservada, la 127.0.0.0/8, esta red es muy especial debido a que en realidad se refiere al mismo equipo por lo que se le llama eco (loopback), así que, en todo equipo hay una dirección 127.0.0.1 y representa a mismo equipo, es muy importante indicar que toda petición que hagamos al loopback, no saldrá del equipo, además de que cualquier programa que tenga abierto un puerto solo en la IP 127.0.0.1 no podrá recibir peticiones de ningún otro equipo.

Redes TCP/IP (parte 1)

Vamos a iniciar con un tema muy teórico, el cual, considero es muy necesario para poder revisar otros temas.

En la actualidad, un sistema de información requiere una red de datos que permita el intercambio de información entre aplicaciones dentro de la misma organización y fuera de ésta, además de el usuario requiere el acceso a este desde dispositivos de diversos tipos (equipos de escritorio, móviles, etc).

A partir del surgimiento de Internet en el mundo comercial su protocolo, el TCP/IP (o en su forma correcta IPv4), se convierte en el estándar de comunicación, por lo que en la actualidad todo dispositivo que trabaja en red, desde un smartphone hasta un servidor, ocupan este protocolo.

Modelo OSI

Haciendo un poco de historia, a principios de los años 80's existían varios tipos de redes, tales como: DECnet, AppleTalk, SNA, etc. Por lo que se adoptó un modelo que debería seguir cualquier tipo de red para poder asegurar la interconexión entre éstas, a esto se le llamo el Modelo OSI y está conformado por 7 capas, esto es, desde como se conectan los equipos físicamente hasta el acceso del usuario a la aplicación. Vamos rápidamente a revisar a cada capa y su correspondencia con el protocolo TCP/IP

Capa 1 Nivel Físico

La forma en la cual los dispositivos que conforma una red se conectan se le llama Topología.

 

En la actualidad las topologías que se utilizan son en estrella y en árbol.

En estrella es cuando todos los nodos que forman parte de la red se conectan a un punto común antes llamado hub, ahora switch. Normalmente se utiliza en empresas muy pequeñas y en casas, si ustedes en casa tienen un ruteador para conectarse a Internet ésta es la topología que utilizan.

En árbol es la topología que utilizan prácticamente todas las empresas en la actualidad y consiste en estrellas interconectadas entre sí en forma jerárquica.

La conexión a la red se logra mediante una interfaz (NIC) la cual se conecta al switch por medio de un cable de cobre, fibra óptica o en forma inalámbrica. Aunque ya está de desuso también es posible al conexión mediante una interfaz serial y un convertidor a señal análoga (módem).

Capa 2 Nivel de enlace

Es la encargada de transferir la información entre dispositivos dentro de una red mediante bloques de información llamados tramas.

Estas tramas se encuentran definidas en una norma que, por lo regular, son Ethernet IEEE 802.3 para la comunicación por medio de cable o fibra, y para el caso de las inalámbricas puede ser Wi-Fi 802.11 y WiMAX 802.16 entre otras (incluyendo la telefonía móvil).

La forma en la que se reconoce a qué dispositivo está destinada cada trama es por medio de una dirección única de identificación para cada uno llamada dirección MAC, la cual, es un identificador de 48 bits dividido en 6 números hexadecimales en la forma XX:XX:XX:XX:XX:XX, por ejemplo: 04:00:4F:2C:00:3E

Capa 3 Nivel de red

En esta capa se emplea el protocolo IP y a partir de aquí es posible la comunicación de dispositivos de una red a otra, lo que técnicamente se denomina ruteo.

El intercambio de información en este nivel se realiza mediante paquetes y la forma de identificación entre nodos es por medio de un número único de 32 bits divido en 4 números decimales llamados octetos en la forma XXX.XXX.XXX.XXX, por ejemplo: 192.168.1.10

En entregas posteriores explicaré a más detalle acerca de segmentación y el ruteo, aquí solo diré que en el caso de que el nodo al que se requiere enviar información no se encuentra en la red local se realizará el envío por medio del router definido por default o al que se indique para la ruta específica (ruta estática).

Capa 4 Nivel de transporte

La capa anterior se puede decir que es la que permite la conexión entre nodos, una vez que se logra ésta es necesario enviar y recibir datos por medio del protocolo de transporte.

Para esto, regularmente se utilizan datagramas por medio del protocolo TCP de forma sincronizada, esto es, el primer dato enviado es el primero en recibirse.

También es común el uso de segmentos empleando es protocolo UDP de forma asíncrona, es decir, el protocolo carece de un modo de asegurar que los segmentos serán entregados necesariamente en el orden en el que se enviaron, de hecho, ni siquiera asegura por si mismo que sea recibido (regularmente se utiliza en aplicaciones en donde se requiere hacer el envío de mensajes de una forma simple sin importar si es necesario reenviarlos).

Hasta aquí, podemos deducir que TCP/IP en realidad quiere decir TCP sobre IP, ya que la mayor parte de las aplicaciones se comunican utilizando este par de protocolos.

Capas 5, 6 y 7 Niveles de sesión, presentación y aplicación

Los servicios de las últimas 3 capas del modelo OSI son utilizados en forma total o parcial por los llamados servicios o protocolos de alto nivel según sea el caso.

Entre estos servicios se encuentran: ftp, telnet, smtp, imap, http, etc.

Como se podrá observar, posteriormente aunque es posible accesar directamente a la mayor parte de estos protocolos (el caso más evidente es el del protocolo ftp) por lo regular se utilizan aplicaciones cliente para dicho acceso (tales como browsers, clientes de email, etc)

También quisiera hacer mención que en estas capas es donde se realiza la implementación de "viejos protocolos" para su uso a través de las redes IP. Este es el caso de IPX sobre TCP/IP para NetWare y el caso más interesante es el de NetBIOS sobre TCP/IP para redes Microsoft Windows. Por supuesto que esto es posible gracias al modelo OSI, el cual, ha demostrado que no solo es posible la comunicación entre redes de diverso género, también es posible utilizar los servicios de una para el uso de otra.

Por último, si bien es cierto que, aparentemente, el protocolo IPv4 está por ser desplazado por IPv6, lo único que cambiará será la forma en que se conecten los diferentes dispositivos a través de Internet ya que el cambio sería solamente en la capa 3. De hecho, la idea es que se puedan utilizar las direcciones actuales haciendo solo una "traducción" a las nuevas direcciones IPv6.

Retomando el tema

Antes que nada, quisiera pedir una disculpa a mis 2 lectores por la larga ausencia, a partir de hoy, vuelvo a este espacio esperando poder publicar con más frecuencia.

También les comento que voy a realizar algunos cambios en este blog mi intensión es dar la posibilidad a otras personas que quieran colaborar conmigo para enriquecer este espacio, proximamente les comunicaré cómo.

En todo caso, cualquier comentario será bienvenido en mi cuenta de correo: hjaramillomx@gmail.com

¡Nuevamente sean bienvenidos!

Atentamente,

Héctor Alejandro Jaramillo Zavala

Programación de scripts (parte 2)

En esta ocasión, vamos a ver cómo trabajar con instrucciones de control de flujo.

En cualquier lenguaje de programación, las instrucciones de control de flujo se encargan de evaluar el resultado de una instrucción y ejecutar el código correspondiente según dicho resultado.

Vamos a ver un ejemplo:

$ while true
> do
> echo "Bucle infinito"
> done

Al ejecutar este ejemplo voy a ver a continuación que se repite en forma infinita la cadena “Bucle infinito” hasta que ingrese la secuencia Ctrl-C. Noten que después de escribir “while true” el prompt cambia al caracter ‘>’, esto es porque hasta la instrucción “done” la instrucción esta incompleta.

Además del while contamos con otras instrucciones, las mas comunes son if, for y case.

Vamos a retomar el script del ejercicio anterior, si yo escribía mi nombre como parámetro me devuelve una cadena en la que incluye mi nombre, pero si no escribo el parámetro, simplemente no lo incluye en la cadena que devuelve, vamos a incluirle la condición de que escriba la cadena siempre y cuando el usuario haya escrito el parámetro:

#!/bin/ksh
#
# hola2
# Segunda corrección al script hola
# Revisa si por lo menos hay un parámetro
if test $# -gt 0
then
   echo Hola $1!
fi

Utilizamos la instrucción if para determinar si ejecutamos el comando echo, esto se va a decidir conforme a lo evaluado por la instrucción test. La instrucción test evalúa si la expresión dada es verdadera o no, si es verdadera, concluye con éxito, si no, lo hace con error. Una vez concluida dicha evaluación, if revisa si concluyo en forma correcta, en caso afirmativo, ejecuta todo lo que se encuentra entre la instrucción then y fi.

La instrucción if puede incluir un apartado else para ejecutar en caso de no se cumpla con la condición verdadera. Veamos el siguiente ejemplo:

#!/bin/ksh
#
# hola3
# Tercera corrección al script hola
# Revisa si por lo menos hay un parámetro
if test $# -gt 0
then
   echo "Hola $1!"
# de lo contrario
else
   echo "Escribe un parámetro"
fi

Aquí estoy utilizando else para indicarle que en el caso de que el usuario no escriba ningún parámetro escriba otra cadena solicitándolo.

Hasta ahora hemos visto como utilizar la instrucción test de una forma “canónica”, sin embargo, por lo regular se utiliza en la forma [ ], es decir, las condiciones a evaluar se encierran entre paréntesis rectangulares y ksh hace la sustitución, de esta forma nuestro código quedará más legible.

Vamos a corregir nuevamente nuestro ejemplo, por medio del if, elif y else vamos a evaluar si de mañana, tarde o noche y de acuerdo a eso haremos un saludo “mas apropiado”.

#!/bin/ksh
#
# hola4
# Cuarta corrección al script hola
# Revisa si no hay parámetros
if [ $# == 0 ]
then
        # entonces termina la ejecución
        echo "Escribe un parámetro"
        exit 1
fi
# Obtiene la hora actual entre 0 y 23
HORA=`date +%H`
# Si es entre las 3 de la madrugada y las 12 del día
if [ $HORA -gt 3 -a $HORA -lt 12 ]
then
        echo "Buenos días $1!"
# Si es entre las 12 de día y las 7 de la noche
elif [ $HORA -ge 12 -a $HORA -lt 19 ]
then
        echo "Buenas tardes $1!"
else
        echo "Buenas noches $1!"
fi

Analicemos esto:

En el primer if revisamos si el número de parámetros es igual a cero, es decir, que no se escribió ninguno, de ser cierto, escribimos un mensaje y concluimos la ejecución del script con la instrucción exit, la mejor práctica nos indica que si un script o cualquier programa en Unix concluye en forma incorrecta debe concluir con lo que se denomina “run level” diferente a cero, en este ejemplo le indicamos que concluya con 1.

Después de esto, definimos la variable HORA con la salida del comando date el cual, esta delimitado por acentos graves (`), en ksh, todo lo que se encuentra encerrado entre acentos graves se ejecuta y su salida se inserta en forma de cadena, es decir, suponiendo que son las 6 de la tarde y 3 minutos, el comando date +%H su salida es 18 el shell sustituye `date +%H` por 18 y a la variable HORA le asigna ese valor.

El script continua con un if, en el cual, se evalúa si el valor de HORA es mayor a 3 (-gt) y (-a) si es menor a 12 (-lt) en caso afirmativo da los buenos días, si no, si es mayor o igual a 12 (-ge) y (-a) menor a 19 (-lt) entonces da las buenas tardes, en caso contrario da las buenas noches, porque si no es mañana ni tarde, entonces debe ser noche.

Programación de scripts (parte 1)

En un ambiente “NIX” se le llama intérprete de comandos al programa con el que regularmente llamamos a otros programas para que inicien. Este intérprete llamado “shell” es el equivalente a command.com de DOS y puede ser el Bourne Shell (sh), C-Shell (csh), Korn Shell y en sistemas modernos Borne Again Shell (bash).

Estos shell interpretan las órdenes que ingresamos por medio del teclado y nos permiten automatizar algunas tareas en la que se repiten las mismas órdenes en archivos que agrupan a éstas, estos archivos se les conoce como “scripts”.

En su forma más sencilla, un script simplemente agrupa una o mas instrucciones:

echo Hola, mundo

Para este ejemplo, vamos a crear un archivo llamado hola con el contenido anterior y lo ejecutamos de la siguiente forma:

$ sh hola
Hola, mundo

Cada shell tiene diferencias con respecto a los demás, principalmente entre sh y csh, el ksh y bash son derivados de sh, por lo que casi cualquier script escrito para este shell se puede ejecutar con los otros 2.

El sh es de todos estos el mas “viejo”, existe desde 1977 y su sintaxis es muy simple, en sistemas abiertos como Linux, en realidad el sh es una liga a otro shell, regularmente el bash.

El csh utiliza una sintaxis “inspirada” en el lenguaje C, al menos es lo que llevan años diciendo sus autores, su uso ya no es muy recomendado en la actualidad y las diferentes distros lo mantienen para mantener la compatibilidad, principalmente, de scripts ya muy viejos. Hay sistemas en los que el csh es sustituido por el más moderno tcsh.

El ksh está basado en sh, mantiene la misma sintaxis y tiene mejorías principalmente en lo que respecta a mantener un histórico de comando y la posibilidad de edición de las instrucciones.

El bash está desarrollado para mantener la compatibilidad con sh y su licencia es GNU, por lo que puede ser portado a cualquier "NIX”.

Regularmente la industria reconoce a ksh como el estándar y bash regularmente no tiene problemas para ejecutar scripts desarrollados para ksh por lo que es el que voy a utilizar para estos ejemplos.

#!/bin/ksh
#
# hola1
# Primera correccion al script hola
echo Hola $1!

En los scripts, los renglones que inician con el signo de número de consideran comentarios. Si el comentario inicia con #! el resto se considera el programa con el que se va a ejecutar el script, esta es una manera de “formalizar” al script indicando cual es el shell para el que fue desarrollado, además de que vamos a poder “forzar” su ejecución en el caso de que el usuario utilice otro shell, por estándar, el path completo del ksh es /bin/ksh. La cadena $1 representa a un parámetro que vamos a “pasar” en tiempo de ejecución. Vamos a “hacerlo” ejecutable y lo corremos de la siguiente forma:

$ chmod 755 hola1
$ ./hola1 Alejandro
Hola Alejandro!

Con el comando chmod activamos el “bit de ejecución” para todos, igual hubiera funcionado chmod +x hola1. Después de esto, lo ejecutamos con ./hola1, esto lo hice así debido a que, regularmente, el directorio actual no está incluido en el path de ejecución (variable PATH). Para los siguientes ejemplo voy a agregar el directorio al path de ejecución para evitar confusiones. Observen que después del nombre del script le dí un espacio y continuación escribí mi nombre, esta cadena es llamada parámetro.

Observen que ejecuta el echo dentro del script sustituyendo a $1 con la cadena “Alejandro”, en ksh, el signo $ al inicio de un identificador representa el valor de una variable de entorno, es decir, que al aparecer la cadena $var va a reemplazarla por el valor de la variable var. Esta variable debe estar definida previamente de la forma: var=valor, por ejemplo:

$ var1=Alejandro
$ var2=Jaramillo
$ echo $var1 $var2
Alejandro Jaramillo

Observen algo muy importante, para definir una variable no se utiliza el signo $.

Existen variables ya predefinidas, algunas son:

# Número de parámetros
1..9 Parámetro 1 al 9
? Valor devuelto por último comando ejecutado
PWD Directorio actual
PATH Path de búsqueda para ejecutables

En siguientes entradas continuaremos con este tema.

Uso de SSH (parte 2)

El SSH nos permite intercambiar archivos mediante los comandos sftp y scp, para poder usar esta funcionalidad es indispensable tener activo el sftp en el archivo de configuración del sshd normalmente llamado /etc/ssh/sshd_config. A continuación el renglón que lo activa:

Subsystem       sftp    /usr/lib/ssh/sftp-server

La forma de transferir es muy semejante al ftp y al rcp, a continuación muestro un ejemplo de cómo usar el sftp:

hajarami@ubuntu:~$ sftp solaris10
Connecting to solaris10...
sftp> put httpd-2.2.16.tar.gz
Uploading httpd-2.2.16.tar.gz to /export/home/hajarami/httpd-2.2.16.tar.gz
httpd-2.2.16.tar.gz                             100% 6220KB 345.5KB/s   00:18
sftp> quit

Como observarán es muy similar su uso al ftp normal se suben archivos con put y se bajan con get.

El scp es prácticamente igual al rcp:

hajarami@ubuntu:~$ scp php-5.3.3.tar.gz solaris10:/export/home/hajarami
php-5.3.3.tar.gz                                 100%   13MB 647.4KB/s   00:21

La sintaxis se resumen como “scp [servidor1:][path1/]archivo1 [servidor2:]path2[/archivo2]”. En el ejemplo estamos transfiriendo el archivo php-5.3.3.tar.gz local al servidor solaris10 en el path /export/home/hajarami.

Observarán que es muy sencillo su uso y la ventaja de esto es que no existe el riesgo de que alguien pudiera “interceptar” nuestro archivo.