Para empezar, un shell-script no es más que un pequeño programa a base de los propios “comandos” de linux y algún recurso más típico de programación como los bucles, o las sentencias de comparación. Es algo parecido a los batch de Microsoft pero muchísimo más potente.

Para empezar, al igual que en Windows o MS-DOS los ficheros batch tenían la extensión “.bat”, en Linux, aunque esto es absolutamente prescindible, se suele asociar la extensión “.sh” a los bash-script.

Estos archivos son simplemente ficheros de texto con todos los comandos que vayamos a ejecutar. Por lo tanto usaremos un editor de textos para crearlo. En este ejemplo usaremos nano, ya que lo hemos utilizado en otros ejemplos por su sencillez.

Crearemos un archivo llamado backup.sh. Para ello tecleamos

nano backup.sh

y ya estaremos en condición de empezar nuestro primer y muy simple bash-script.

Todos empiezan indicando donde se encuentra el ejecutable de nuestro tipo de shell. Como queremos que este pequeño script sirva para poder hacer el backup en el servidor de nuestro proveedor de internet, habrá que saber que tipo de shell están usando allí. Esto solo será posible si tenemos acceso por SSH, como es mi caso. Una vez que hayamos entrado en nuestro servidor tecleamos:

echo $SHELL

Y nos responderá dónde se encuentra, y por ende el tipo. En mi caso la salida a ese comando es:

/bin/bash

Esto me dice que estoy usando bash como shell, porque el ejecutable se encuentra en /bin/bash. Como ya sabemos donde se encuentra nuestro shell escribiremos la primera línea de nuestro shell-script que será:

#!/bin/bash

A continuación copiaremos todos los archivos de WordPress a un directorio que llamaremos backup. Para hacer esto escribiremos lo siguiente en nuestro archivo

mkdir backup
cp -R wp* ./backup
cp *.php ./backup
cp .* ./backup
cp *.text ./backup
cp *.ht* ./backup

Con la primera línea creamos el directorio backup. La segunda copia todos los archivos y directorios que comienzen por “wp”. Sin embargo como existen algunos ficheros de WordPress que no comienzan por “wp” y nos interesan, con la tercera línea copiamos todos los archivos “php” a nuestro directorio de copia de seguridad.

Como aún nos interesan copiar algunos tipos de fichero que no están contemplados en las líneas anteriores, usaremos la cuarta línea para copiar todos los archivos ocultos (en linux son los que empiezan por “.”). Fundamentalmente es .htaccess, que es un archivo que se usa para configurar en cierto modo Apache, y del cual hace uso wordpress.

En la quinta y sexta línea copiamos los ficheros de texto y html que suele crear wordpress en su instalación. Son completamente prescindibles, pero no obstante los copiaremos.

Guardamos (Control + O) y salimos (Control + X). Este archivo tiene que estar al nivel en el que se encuentran el resto de los archivos principales de worpdress como el “index.php”.

Ahora habrá que hacer que este archivo sea “ejecutable”. Para ello usamos el comando chmod, haciendo “ejecutable” con la opción +x el archivo backup.sh, es decir ejecutaremos la siguiente orden.

chmod +x backup.sh

Ya tan sólo nos queda ejecutarlo. Y esto se hace de la siguiente forma:

./backup.sh

No olvidéis el “./” del comienzo, sino no os funcionará.

Obviamente esto es mejorable en múltiples aspectos, no es más que un pequeño ejemplo de un primer shell-script que además nos sirva de algo. Aún nos quedaría hacer una copia de la base de datos y controlar
múltiples aspectos de dicha copia, pero podría servir de base.

Saludos.

Una vez que los desarrolladores consideran que la distribución actualmente en “testing” tiene la suficiente madurez y estabilidad la “congelan” y desde ese momento sólo se le aplicarán actualizaciones de seguridad y parches para corregir errores en los distintos programas. Es el primer paso para que ésta pase a ser la distribución “stable”.

En ese periodo de tiempo, tanto “stable” como “testing” reciben pues el mismo tratamiento.

Una vez que se considera que la rama “testing” está lo suficientemente “madura” ésta pasa a ser la distribución “stable”, y en poco tiempo todo lo que hay en “unstable” empieza a subirse a la nueva distribución “testing”, es decir, de nuevo dos ramas son prácticamente iguales pero en este caso”por abajo”.

Por otro lado la extinta “stable” pasa a “oldstable” donde quedará durante un tiempo prudencial dándosele soporte sobre todo en cuestiones de seguridad.

En ese momento los nombres clave de cada distribución, menos “Sid” se intercambian. Es fácil de entender con un ejemplo. Actualmente tenemos la siguiente organización:

• Oldstable: Sarge
• Stable: Etch
• Testing: Lenny
• Unstable: Sid (por siempre jamás)

Cuando Lenny pase a ser la distribución estable esto quedará así:

• Oldstable: Etch
• Stable: Lenny
• Testing : Aún no se sabe el nombre, o al menos yo no lo sé
• Unstable: Sid (por siempre jamás)

Como curiosidad, todos los nombres proceden de los personajes de Toy Story. Sarge el “comandante” de los soldaditos de plástico, Etch es el “Teleskecth”, Lenny son los prismáticos y Sid es el niño malo de la primera parte.

Por último, cuando tengas instalado tu Debian puedes “fidelizarte” a u nombre o una rama.

Si le indicas a tu sistema que siempre sea “stable”, “testing” o “unstable” pasarás, por ejemplo, de Etch a Lenny si eliges “stable” de forma “más o menos transparente”. Esto es una simplificació, pero sería así.
Por otro lado si a tu sistema le dices que seas “Lenny” lo serás hasta que te hartes, independientemente de que llegue a “oldstable o más allá”.

Todo esto lo veremos mejor cuando os explique como va el aptitude.

Saludos.

Sin embargo Debian tiene varios “sabores” y actualmente uso Lenny, pero también existen Etch y Sid, y aunque esto lo sabe “todo el mundo”, si a tí no te suena puedes seguir leyendo e intentaré explicártelo.

Debian tiene tres “ramas” principales: “stable”, “testing” y “unstable”, y las dos primeras suelen tener nombres propios que cambian con el tiempo. Actualmente son “Etch” y “Lenny” respectivamente. La última siempre se llama “Sid”

La distribución “stable” está más pensada para servidores u ordenadores donde prive mucho más la seguridad y estabilidad que la necesidad de tener la última versión de cada programa instalado. Las actualizaciones que se hacen sobre los programas y/o el Kernel son siempre de seguridad, y más que actualizar versiones, se “parchean”. ¿Qué quiere decir esto?. Pues que si tienes “Etch” tendrás, por ejemplo, la versión 1.4.4-1 de Amarok, mientras que en “testing” tendrás la 1.4.8-1. Este dato está tomado a día de hoy. Y se quedará en la versión 1.4.4 casi seguro hasta el final de su ciclo de vida, pero parcheando todos los problemas de seguridad y estabilidad que sean inherentes a esa versión.

Si padeces “versionitis”, o te gusta experimentar, entonces tu versión es “testing”, que es la que yo uso. Es la versión ideal para tu pc de escritorio de casa. Las versiones van siendo introducidas en esta versión una vez que cumplan unos criterios mínimos de estabilidad y fiabilidad. Es decir, que no tendrá la versión beta del Amarok 2, pero sí la última estable una vez pasado un tiempo prudencial.

Por último está la versión “unstable” donde podrás encontrar las últimas versiones de los programas casi al mismo tiempo que salen. Está pensada para que los desarrolladores de Debian trasteen y experimenten con los programas. Una vez que éstos deciden que los programas cumplen sus criterios de calidad, pasan a “testing”.

Para que te hagas una idea “Etch” tiene actualmente la versión 3.5.5 de KDE y “Lenny” la 3.5.8, y yo recuerdo haber pasado en my Lenny desde la 3.5.6.

Hay mucho más que hablar sobre las versiones, sus nombres, como instalar cada una de ellas, o como pasar de una más estable a otra menos estable, pero lo dejaremos para otra ocasión.