Planificació i automatització de tasques

Les característiques que s’esperen d’un programari de planificació de tasques són:

• Permetre l’execució de tasques de manera automàtica.
• Tenir interfícies que ajudin a definir els fluxos de treballs o dependències entre tasques.
• Tenir interfícies que permetin la monitorització i el seguiment de les execucions de les tasques.
• Disposar d’algun mecanisme de prioritats o cues per controlar l’ordre d’execució dels treballs no relacionats.

Qualsevol programari que inclou totes o alguna d’aquestes característiques el podem considerar com un programari amb capacitats de planificació de tasques.

Des del punt de vista històric, podem distingir dues èpoques principals pel que fa als planificadors de tasques: l’era de l’ordinador central (mainframe) i l’era dels sistemes oberts i la informàtica distribuïda.

L’època de l’ordinador central es caracteritza pel desenvolupament de solucions de planificació sofisticades que inclouen característiques de planificació avançades i que formen part de les eines de gestió del propi sistema del mainframe. En l’ordinador central d’IBM, per exemple, el job control language (JCL) oferia des de bon principi la funcionalitat de gestionar dependències entre treballs.

En l’època dels sistemes oberts, una gran diversitat de programari ofereix capacitats bàsiques de planificació de tasques:

• La majoria de sistemes operatius, com ara Windows o Unix i derivats, proporcionen eines de planificació que segueixen un model senzill per a l’execució de les tasques basat en els esdeveniments d’un calendari o en la càrrega del sistema en un moment determinat.
• Els serveis d’allotjament web ofereixen capacitats de planificació de treballs per mitjà d’un tauler de control o una solució de tipus webcron.
• D’altres aplicacions de diverses àrees, com ara programaris de còpies de seguretat, ERP, etc., incorporen facilitats per planificar les tasques pròpies de l’aplicació.

En general, els sistemes operatius i aplicacions de l’era dels sistemes oberts no ofereixen la possibilitat de planificar l’execució de tasques més enllà d’una única instància de sistema operatiu o fora de l’àmbit del programa específic. A mesura que el nombre i la varietat de plataformes s’estén, les capacitats bàsiques de planificació de tasques es queden curtes i sorgeix la necessitat de sistemes de planificació avançats propers als planificadors estàndards dels ordinadors centrals i que a més proporcionin la possibilitat d’integrar diferents tipus de plataformes.

Normalment, les organitzacions mitjanes i grans disposen d’un nombre elevat de servidors amb diferents sistemes operatius i aplicacions, i un conjunt molt variat i molt ampli de treballs per executar, que poden tenir dependències complexes entre ells més enllà de la dimensió del temps o la càrrega del sistema. Per satisfer les demandes d’aquest tipus de centres, hi ha programaris específics de planificació de treballs –o de gestió de càrrega de treball– que són compatibles amb i que integren diverses plataformes i aplicacions i que disposen de característiques avançades com ara:

• Planificació de temps real basada en esdeveniments imprevisibles externs.
• Reinicialització automàtica de tasques i recuperació en cas de fallades.
• Alerta i notificació al personal d’operacions.
• Generació d’informes d’incidents.
• Registres d’auditoria per a propòsits de compliment de normatives.

En aquests sistemes hi ha diversos esquemes per decidir quin treball s’ha d’executar en un moment determinat. Per exemple, alguns paràmetres que poden ser considerats són:

• La prioritat de la feina.
• Els recursos de còmput existents.
• L’existència de la clau de llicència, si el treball està utilitzant programari amb llicència.
• El temps d’execució assignat a un usuari.
• El nombre de treballs permesos simultàniament a un mateix usuari.
• El temps estimat d’execució de la tasca.
• El temps transcorregut de la tasca.
• La disponibilitat de perifèrics.
• L’ocurrència d’esdeveniments requerits.

Aquests productes són complexos i solen oferir una interfície gràfica d’usuari amb un únic punt de control per a la definició i seguiment de les execucions de les tasques de tota la xarxa distribuïda d’ordinadors. La interfície d’usuari del programari sol ser de tipus web i normalment també incorpora una interfície de línia d’ordres.

La figura mostra gràficament un entorn amb un sistema distribuït de planificació de treballs i una arquitectura típica implementada en aquests tipus de planificadors anomenada arquitectura de mestre/agent. El nucli del programari de planificació de treballs s’instal·la en una sola màquina (mestre), mentre que en les màquines de producció només s’instal·la un component molt petit (agent) que espera les ordres del mestre, les executa i li retorna el codi de sortida. Determinats serveis (FTP, SNMP, programes Java, etc.) no requereixen cap agent. Qualsevol màquina o dispositiu client amb un navegador permet el control i seguiment de les tasques.

Hi ha un ampli ventall de programari especialitzat en planificació de tasques per a sistemes distribuïts. L’elecció d’una eina sòlida continua sent essencial per a qualsevol empresa amb un nombre significatiu de servidors. Aquestes eines poden ser molt cares quan s’adquireixen de venedors tradicionals de programari de gestió de les TIC (tecnologies de la informació i la comunicació), però també hi ha eines de venedors independents a preus més competitius.

Les eines bàsiques de planificació proporcionades amb sistemes operatius com ara Unix i derivats o Windows s’utilitzen en entorns amb un nombre reduït de servidors que no requereixen planificació de tasques distribuïda. A continuació descriurem les més utilitzades en l’actualitat.

El planificador de tasques dels sistemes Windows de Microsoft s’anomena task scheduler, s’instal·la automàticament en el sistema operatiu com un servei i s’inicia cada vegada que el sistema és arrencat.

El task scheduler es pot utilitzar des de la línia d’ordres amb el programa schtasks.exe, però el més habitual és fer servir la interfície gràfica d’usuari a la qual hi accedim a partir de Panell de control > Sistema i seguretat > Eines administratives > Programador de tasques.

La versió actual (2012) del task scheduler és la 2.0. Va ser introduïda amb Windows Vista i incorporada a Windows Server 2008. En aquesta versió la interfície d’usuari té un nou disseny basat en la consola de gestió de Microsoft (MMC, Microsoft management console) i les capacitats de planificació de tasques es milloren respecte la versió anterior, la 1.0.

El task scheduler 2.0 permet seleccionar el tipus d’acció que volem planificar d’entre les següents:

• Executar una aplicació o guió de shell.
• Enviar un correu electrònic.
• Mostrar una caixa de diàleg amb un missatge.

La figura mostra una finestra amb el task scheduler executant-se en un sistema operatiu Windows 7.

Les accions es poden planificar perquè siguin executades quan es produeixi alguna de les condicions següents:

• D’acord amb una programació (a una hora específica una vegada, diàriament, setmanalment o mensualment).
• En obrir o tancar la sessió.
• En iniciar el sistema.
• Quan el sistema entra en estat inactiu.
• En produir-se un esdeveniment determinat del sistema.
• En bloquejar-se o desbloquejar-se l’estació de treball.

En els sistemes de tipus Unix hi ha diverses eines relacionades amb la planificació de tasques:

• El programa cron, un planificador basat en el temps que assumeix que el sistema està sempre en funcionament.
• El programa anacron, que fa les tasques de cron però sense assumir que el sistema està sempre en funcionament. Aquest programa no substitueix a cron, és una eina complementària.
• L’ordre at, la qual es fa servir per fer execucions retardades i planificar tasques que es volen executar una sola vegada a una hora determinada en el futur.

Mentre que cron, anacron i at són eines per executar tasques quan arriba un determinat moment en el temps, hi ha d’altres eines que permeten executar tasques quan es dóna un esdeveniment, per exemple:

• L’ordre batch s’utilitza per executar tasques quan el nivell de càrrega del sistema ho permeti.
• El servei incron està dissenyat per executar tasques quan es produeix un esdeveniment en el sistema de fitxers. incron pot examinar un fitxer específic o un directori sencer i reaccionar a diferents esdeveniments com ara la creació, la modificació o l’esborrat de fitxers, etc.

Si bé tenim a l’abast aquestes i altres eines, el planificador per excel·lència és el cron i és en el que ens centrarem.

Cron ha estat reescrit diversos cops durant la seva història i en podem trobar implementacions, com ara la d’AT&T, que poden diferir lleugerament del cron vixie, que és el que utilitzarem i descriurem en els apartats següents.

Cron és un dimoni (servei) i generalment s’instal·la automàticament en fer la instal·lació del sistema operatiu i queda configurat per ser iniciat amb l’arrencada del sistema. Es pot comprovar l’estat del servei executant l’ordre:

/etc/rc.d/init.d/cron status

També podem veure si el dimoni està en execució mitjançant l’ordre ps:

ps -ef | grep cron

Si per alguna raó cron no està funcionant es pot iniciar el servei amb el superusuari root i amb el guió de shell d’inicialització corresponent:

/etc/rc.d/init.d/cron start

Un fitxer de crontab conté instruccions per al servei cron en la forma general: “Executa aquesta ordre a aquesta hora en aquesta data”.

La planificació de tasques amb cron es pot fer de dues maneres, a nivell d’un usuari particular i a nivell de tot el sistema i els fitxers de crontab en cada cas difereixen lleugerament.

Quan el cron és utilitzat a nivell d’usuari, les línies d’un fitxer de crontab es formen amb sis camps separats per espais o tabuladors de la manera següent:

minut hora diaDelMes mes diaSetmana ordre

Els cinc primers camps indiquen el calendari d’execució i el sisè camp especifica la tasca que s’ha d’executar. Cada línia correspon a una tasca i no hi ha límit de tasques.

En el cas que el cron sigui utilitzat a nivell de sistema, afegim a les línies del fitxer de crontab un sisè camp per indicar el nom de l’usuari que ha d’executar l’ordre:

minut hora diaDelMes mes diaSetmana usuari ordre

En tots els casos, el significat de cada camp és el següent:

• minut: indica el minut de l’hora en què l’ordre serà executada. Ha de ser un valor entre 0 i 59.
• hora: indica l’hora en què l’ordre serà executada. Ha de ser un valor entre 0 i 23, éssent 0 la mitjanit.
• diadelmes: indica el dia del mes en què l’ordre serà executada. Ha de ser un valor entre 1 i 31.
• mes: Indica el mes en què l’ordre serà executada. Pot ser indicat numèricament (un valor entre 1 i 12) o amb les tres primeres lletres del nom del mes en anglès (jan, feb, mar, etc.).
• diasetmana: indica el dia de la setmana en què l’ordre serà executada. Pot ser indicat numèricament (un valor entre 0 i 7, sent tant el 0 com el 7 el diumenge) o amb les tres primeres lletres del nom del dia en anglès (mon, tue, etc.).
• usuari: indica l’usuari que executarà l’ordre (només a /etc/crontab).
• ordre: ordre, script o programa que es vol executar. Aquest camp ocupa fins al final de la línia; pot contenir múltiples paraules i espais.

Es poden utilitzar els símbols especials següents per indicar els valors dels camps:

• Un asterisc, *, indica tots els valors possibles.
• Llistes de valors separats per comes. Per exemple: 1,2,5,9.
• Rangs de valors separats pel guió. Per exemple: 8-11 (indica 8, 9, 10 i 11).
• Intervals periòdics mitjançant */valor. Per exemple: */5 en el camp minut indica cada 5 minuts: 5, 10, 15, 20, 25…

La figura mostra gràficament el format d’una línia d’un fitxer de crontab de sistema.

La taula mostra exemples d’expressions temporals de cron.

# Executar 5 minuts després de la mitjanit cada dia
5 0 * * * $HOME/bin/diari.sh
# Executar a les 2.15 pm el primer dia de cada mes
15 14 1 * * $HOME/bin/mensual.sh

Hi ha uns valors predefinits que es poden utilitzar per substituir tota l’expressió de cron. La taula mostra quins són aquests valors.

Hi ha diverses variables d’entorn que són establertes de manera predeterminada pel servei de cron. Per exemple, la variable SHELL s’estableix per defecte a /bin/sh per indicar que les tasques s’executin amb aquest shell, o la variable PATH s’estableix a /usr/bin:/bin.

SHELL=/bin/bash
PATH=~/bin:/usr/bin/:/bin
5 0 * * * $HOME/bin/diari.sh
15 14 1 * * $HOME/bin/mensual.sh

El planificador de tasques cron permet que cada usuari tingui el seu propi fitxer de planificació de tasques o crontab. Els crontab dels usuaris es guarden al directori /var/spool/cron/crontabs (aquest directori pot variar segons la versió d’Unix/Linux) amb el nom de l’usuari del sistema que ha generat el fitxer. Per exemple, hi podem trobar un fitxer anomenat root per al crontab del superusuari root, un fitxer anomenat alba per al crontab de la usuària alba, i així per a cada usuari del sistema.

En lloc que cada usuari pugui modificar al seu gust els fitxers que hi ha al directori /var/spool/cron/crontabs, existeix un programa denominat crontab que serveix per gestionar aquests fitxers, però d’una forma controlada.

La sintaxi de l’ordre crontab és la següent:

crontab [ -u usuari ] fitxer
crontab [ -u usuari ] { -e | -l | -r }

L’opció -u només la pot utilitzar root i permet gestionar el crontab d’un altre usuari en lloc del propi.

La primera forma d’ús de crontab permet a l’usuari que executa l’ordre generar un fitxer de crontab a partir d’un fitxer creat prèviament. L’usuari crea un fitxer de text amb les línies corresponents a les tasques que vol planificar amb el format adequat, és a dir:

minut hora diaDelMes mes diaSetmana ordre

Un cop creat el fitxer de planificació de tasques, l’usuari executa l’ordre crontab posant com a argument el nom del fitxer:

crontab fitxer

Per exemple, la usuària maria crea un fitxer anomenat tasques que conté la línia següent:

0 22 * * * /home/maria/proces.sh

I a continuació executa l’ordre:

crontab tasques

Si el fitxer de tasques no conté errades sintàctiques, l’ordre crontab generarà el fitxer /var/spool/cron/crontabs/maria amb la tasca planificada per la usuària maria. En cas contrari, l’ordre dóna un missatge informatiu indicant l’errada trobada i no instal·la el fitxer de crontab.

L’ordre crontab és pot utilitzar sense necessitat de rebre un fitxer com a argument. En aquest cas la sintaxi és:

crontab -e

L’ordre anterior obre l’editor preestablert de l’usuari i permet crear o modificar el fitxer de planificació de tasques directament. En sortir i desar el fitxer, si crontab no hi troba errades, crearà o modificarà el fitxer corresponent a /var/spool/cron/crontabs amb el nom de l’usuari.

Amb l’opció -l, crontab permet llistar les tasques que té planificades l’usuari:

crontab -l

Amb l’opció -r s’eliminen totes les tasques de cron de l’usuari:

crontab -r

export EDITOR=/usr/bin/gedit

crontab -e

* * * * * date >> /home/usuari/provacron.log

tail -f /home/usuari/provacron.log

Els fitxers de crontab ubicats al directori /var/spool/cron/crontabs són fitxers de text pla. No obstant això, quan treballem amb l’usuari root i volem modificar el seu crontab o el de qualsevol altre usuari, no hem d’editar directament aquests fitxers, sinó que hem d’utilitzar l’ordre crontab igual que fan la resta d’usuaris per assegurar-nos que no fem errades de sintaxi en els camps de planificació de les tasques.

El format de les línies del fitxer és:

minut hora diaDelMes mes diaSetmana usuari ordre

Els canvis en el fitxer /etc/crontab prenen efecte pel sol fet d’editar-lo i modificar-lo, és a dir, a diferència del que fem amb els crontab d’usuari, no cal executar l’ordre crontab per instal·lar-lo.

El fitxer /etc/crontab es crea amb un contingut per defecte similar al següent:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
 
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
# m h dom mon dow usercommand
17 * * * * root run-parts --report /etc/cron.hourly
25 6 * * * root run-parts --report /etc/cron.daily
47 6 * * 7 root run-parts --report /etc/cron.weekly
52 6 1 * * root run-parts --report /etc/cron.monthly

Les primeres línies sense símbol de comentari són definicions de variables. La variable SHELL indica el shell amb el qual s’han d’executar les tasques, i la variable PATH, els camins dels directoris en els quals cron buscarà les tasques que s’han d’executar.

Després de les variables, hi ha les línies que executen les tasques planificades:

• La primera línia indica que s’executi la tasca en el minut 17 de cada hora de tots els dies.
• La segona línia indica que s’executi a les 6.25 am de cada dia.
• La tercera línia, a les 6.47 am tots els diumenges.
• La darrera, a les 6.52 am del primer de cada mes.

L’usuari especificat per executar totes les tasques és root i l’ordre planificada sempre és run-parts, però posant com a argument en cada cas el nom d’un directori diferent:

• /etc/cron.hourly
• /etc/cron.daily
• /etc/cron.weekly
• /etc/cron.monthly

Com a administradors del sistema, podem desar un fitxer executable pel shell (guió de shell, programa compilat, etc.) dins de qualsevol d’aquests directoris perquè sigui executat una vegada cada hora, dia, setmana o mes, respectivament, a l’hora configurada en el fitxer /etc/crontab. Per exemple, si es deixa un shell script dins de /etc/cron.daily s’executarà a les 6.25 am de cada dia.

En el fitxer /etc/crontab es poden afegir línies addicionals per executar qualsevol altra ordre, però no és recomanable, ja que aquest fitxer pot ser sobreescrit en fer actualitzacions del sistema. És més recomanable posar les tasques en els directoris /etc/cron.hourly, /etc/cron.daily, etc. o bé utilitzar els crontab d’usuari.

0 22 * * * root /usr/local/diari.sh
0 8,20 * * * helena -s "Sistema viu" helena@ioc.cat

En alguns sistemes, hi ha també un directori anomenat /etc/cron.d on es poden col·locar fitxers de crontab. Els fitxers d’aquest directori tenen el mateix format que el fitxer /etc/crontab, és a dir, les línies inclouen el camp de l’usuari:

minut hora diaDelMes mes diaSetmanausuari ordre

En general, l’administrador no hauria d’utilitzar el directori /etc/cron.d/. La finalitat d’aquest directori és permetre que les aplicacions que requereixen un control més fi de la seva planificació que el proporcionat pels directoris /etc/cron.daily, /etc/cron.weekly, etc, afegeixin un fitxer propi de crontab a /etc/cron.d. Aquests fitxers han de dur el nom del paquet de programari que els instal·la i sovint són enllaços a fitxers on, tant l’enllaç com el fitxer, tenen com a propietari l’usuari root.

ls /etc/cron.d/ 

anacron mdadm php5

cat php5 

# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime
 
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm

Un exemple d’aplicació que trobarem que instal·la un fitxer de crontab al directori /etc/cron.d és anacron. És un programari que no pretén substituir a cron, sinó que funciona amb cron. El sistema de cron implica que la màquina està sempre encesa, cosa que és certa en la majoria dels casos quan parlem de servidors, però per a aquells casos que això no és així, per exemple quan es tracta d’estacions de treball, és millor utilitzar anacron, que verifica si l’acció no es va fer quan l’hauria hagut de fer, i llavors l’executa.

El cron es desperta cada minut, examina tots els fitxers de crontab existents i executa les tasques que tenen els camps que es compleixen en aquell precís minut. Qualsevol sortida de la tasca s’envia per correu electrònic a l’usuari que l’executa o, si existeix, a l’usuari indicat en la variable d’entorn del crontab anomenada MAILTO.

Tenim diverses opcions de redirecció. Les més utilitzades són:

• Ignorar la sortida redirigint a /dev/null: ordre > /dev/null
• Crear o afegir a un fitxer de registre: ordre » nom_fitxer
• Redirigir també la sortida d’errors: ordre » nom_fitxer 2>&1

Per exemple:

5 0 * * * $HOME/bin/diari.sh >> $HOME/tmp/diari.out 2>&1

La línia anterior especifica que s’executi cada dia a les 0.05 el guió de shell $HOME/bin/diari.sh. La sortida d’aquesta tasca està redirigida amb l’operador » cap a un fitxer anomenat $HOME/tmp/diari.out, de manera que cada vegada que el guió de shell s’executa, la seva sortida es va afegint al final del fitxer. La sortida d’errors també està redirigida amb 2>&1 per tal que, si hi ha errors, s’afegeixin al mateix fitxer de sortida.

Per exemple, podem trobar un rastre com el següent:

Feb 27 12:33:02 saturn crontab[2671]: (umart) BEGIN EDIT (umart)
Feb 27 12:33:23 saturn crontab[2671]: (umart) REPLACE (umart)
Feb 27 12:33:23 saturn crontab[2671]: (umart) END EDIT (umart)
Feb 27 12:34:01 saturn /usr/sbin/cron[1253]: (umart) RELOAD (crontabs/umart)
Feb 27 12:34:01 saturn /USR/SBIN/CRON[2677]: (umart) CMD (echo hola)

En les línies anteriors podem llegir que l’usuari umart està treballant en el servidor saturn i ha editat el seu crontab el 27 de febrer. Després el cron s’ha recarregat i s’ha executat una tasca del mateix usuari.

Podem configurar syslog perquè es creï un fitxer de registre exclusiu per a cron. Per fer-ho cal editar el fitxer de configuració /etc/rsyslog.conf i treure el símbol de comentari, #, de la línia següent:

#cron.*   /var/log/cron.log

Si volem activar un nivell superior de detall de registre de l’activitat de cron, hem d’editar el fitxer de configuració de cron anomenat /etc/default/cron i eliminar el símbol de comentari, #, de la línia EXTRA_OPTS=”-L 2”. El contingut del fitxer quedarà així:

# Cron configuration options
...
# Extra options for cron, see cron(8)
# Set a higher log level to audit cron's work
EXTRA_OPTS="-L 2"

És possible controlar quins usuaris poden o no utilitzar els serveis de cron d’una manera molt senzilla amb els fitxers /etc/cron.allow i /etc/cron.deny.

Si el fitxer /etc/cron.allow existeix, llavors l’usuari ha d’estar llistat (un usuari per línia) dins d’aquest fitxer per poder fer servir l‘ordre crontab. Si el fitxer /etc/cron.allow no existeix però existeix el fitxer /etc/cron.deny, llavors l’usuari no ha d’estar llistat dins de /etc/cron.deny per poder usar l’ordre crontab. Si es vol evitar que tots els usuaris utilitzin cron es pot escriure ALL dins del fitxer /etc/cron.deny.

Cal tenir en compte les consideracions següents:

• Si cap dels dos fitxers existeix, per defecte tots els usuaris del sistema poden planificar treballs utilitzant l’ordre crontab.
• Si els dos fitxers existeixen, llavors el fitxer /etc/cron.allow té precedència, és a dir, el fitxer /etc/cron.deny s’ignora i l’usuari ha d’estar llistat dins de /etc/cron.allow per poder usar l’ordre crontab.

La figura il·lustra gràficament el funcionament del control d’accés a cron.

Independentment de l’existència d’aquests dos fitxers, l’usuari root sempre pot planificar tasques, ja sigui amb l’ordre crontab o amb el fitxer de sistema /etc/crontab i els directoris de cron situats a /etc.

Hi ha diverses interfícies que es poden utilitzar per configurar cron de manera gràfica. Els entorns d’escriptori porten els seus paquets respectius per fer la configuració de cron gràficament. Per exemple:

• Amb GNOME podem instal·lar el paquet gnome-schedule. Una vegada instal·lat l’executem des d’Aplicacions > Eines del sistema > Tasques programades.
• Amb KDE tenim el paquet kde-config-cron, que és part del mòdul d’administració de KDE.

La figura mostra l’aspecte del planificador de tasques de GNOME visualitzant el següent crontab d’un usuari:

5 0 * * * $HOME/bin/diari.sh
15 14 1 * * $HOME/bin/mensual.sh

La majoria d’eines gràfiques d’administració del sistema també permeten configurar cron. Per exemple, l’eina d’administració Webmin incorpora un mòdul que permet configurar la planificació de tasques de cron de manera gràfica, en remot i des d’un navegador web.

Si sabem treballar amb cron i configurar-lo des de la línia d’ordres, l’ús de qualsevol d’aquestes eines gràfiques és immediat i explicar el seu funcionament és innecessari.

La programació de shell scripts i la utilització d’un planificador de tasques ens facilita l’automatització de moltes de les tasques requerides per al manteniment i la configuració del sistema. A continuació veurem exemples de tasques que típicament requereixen ser automatitzades i utilitzarem el llenguatge de guions Bash per implementar-les.

En primer lloc veurem tasques que s’automatitzen i que normalment també es planifiquen per ser executades de manera periòdica, com són les còpies de seguretat i el manteniment dels fitxers de registre del sistema. Per fer la planificació de l’execució d’aquestes tasques utilitzarem cron.

Després veurem l’automatització de tasques del sistema que en general no requereixen d’un planificador de tasques per ser executades, com ara la gestió d’usuaris, que normalment executem de manera interactiva quan sorgeix la necessitat, i l’automatització de l’inici de serveis que es realitza amb l’arrencada del sistema.

En informàtica, una còpia de seguretat (en anglès backup) és la còpia d’informació que es realitza per tal de ser restaurada en cas de pèrdua de dades o en cas de ser requerida posteriorment.

Les còpies de seguretat poden ser del sistema o de les dades. Les còpies del sistema tenen com a objectiu poder arrencar un sistema després d’un incident de seguretat i per tant realitzen una còpia dels fitxers del sistema operatiu i del programari instal·lat. D’altra banda, les còpies de seguretat de dades pretenen recuperar informació i realitzen còpies de fitxers de dades o bases de dades.

Normalment les dades es copien en un mitjà d’emmagatzemament diferent al de l’origen de les dades, com poden ser discos durs externs, CD-ROM, cintes magnètiques (DAT), etc. i, cada vegada més, s’utilitzen sistemes de còpia de seguretat remota que realitzen les còpies de manera automàtica a través de la xarxa o Internet.

Per tal de decidir quina tecnologia utilitzarem per dur a terme les còpies de seguretat hi ha tres factors clau a tenir en compte: el volum de dades a copiar, el cost econòmic del mitjans d’emmagatzemament i l’operativitat de la solució escollida tant pel que fa al temps de còpia com al de recuperació. Algunes decisions que s’han de prendre són:

• La periodicitat de les còpies. Com més alta és la freqüència més capacitat de recuperació es té.
• El nombre de còpies. Si es realitza més d’una còpia i aquestes es desen en ubicacions separades s’augmenta la seguretat.
• La retenció de les còpies. Com més còpies antigues es guarden es té més capacitat de recuperar informació de fa més temps.
• El model de còpia. Hi ha diversos models (còpia completa, diferencial o incremental) que analitzem més endavant i que són estratègics pel que fa al temps de còpia i recuperació, així com a la quantitat d’espai requerit per guardar les còpies.

Existeixen molts programaris específics de còpies de seguretat i recuperació. Ara bé, en els sistemes de tipus Unix aquestes tasques també poden fer-se fàcilment mitjançant scripts planificats amb cron que utilitzen les eines bàsiques que ens proporciona el sistema, com tar, cpio o el parell dump/restore.

En els exemples que mostrarem utilitzarem l’eina tar per empaquetar fitxers i l’eina gzip per comprimir les dades. Empaquetar vol dir ajuntar dos o més fitxers en un de sol (paquet) i comprimir vol dir agafar el fitxer o paquet i comprimir-lo. A la taula es mostra un resum del funcionament de les eines tar i gzip i l’extensió que se sol posar als fitxers que es generen.

L’eina tar (tape archiver) va ser dissenyada originalment per transferir fitxers de disc a una cinta magnètica i viceversa, tot i que ara s’utilitza per empaquetar dades directament sobre qualsevol fitxer o dispositiu. Per exemple, si en el sistema hi ha muntada una unitat de cintes disponible a partir del nom de fitxer de dispositiu /dev/st0 i hi tenim posada una cinta, podem copiar-hi les dades del directori anomenat /dades així:

tar cf /dev/st0 /dades

Una vegada copiades les dades, podem utilitzar les diferents opcions de tar que ens permeten veure i extreure les dades.

L’estratègia més simple per realitzar una còpia de seguretat és copiar totes les dades diàriament. Aquest tipus de còpies són factibles per a sistemes amb un volum de dades petit, però quan la quantitat de dades és gran, cal combinar altres estratègies per dur a terme les còpies. Els tipus de còpies que es poden fer són els següents:

• Copia de seguretat completa. És aquella que inclou tots els fitxers d’un determinat conjunt de dades sense tenir en compte les còpies de seguretat prèvies. També les podem anomenar còpies de nivell zero.
• Còpia de seguretat diferencial. És una còpia de tots els fitxers d’un conjunt de dades determinat que ha estat afegit o modificat des de la darrera còpia de seguretat completa. Per restaurar un conjunt de dades, s’ha de restaurar el nivell zero i el diferencial més recent. Un diferencial inclou els mateixos fitxers que el diferencial anterior. Així, en el cas típic, la mida de cada diferencial augmentarà fins que s’executi el proper nivell zero.
• Còpia de seguretat incremental. Es tracta d’una còpia de seguretat de tots els fitxers que hi ha en un determinat conjunt de dades que han canviat des de la darrera còpia de seguretat (de qualsevol tipus). Així, donada una còpia de nivell zero el dilluns, si fem una incremental el dimarts només obtindríem els fitxers nous o canviats des del dilluns. Una incremental feta el dimecres inclouria els fitxers que es van afegir o modificar des del dimarts. Això contrasta amb la diferencial. El que convé recordar és l’ordre de restauració. Per restaurar completament el conjunt de dades, s’ha de recuperar en primer lloc la còpia de nivell zero i després tots els increments en la mateixa seqüència en què van ser creats.

Tenint en compte les definicions que acabem de donar, en funció dels requeriments de cada sistema, les estratègies que s’implementen amb més freqüència són tres:

• Còpia completa diària.
• Còpia completa setmanal i còpia diferencial diària
• Còpia completa setmanal i còpia incremental diària.

La primera estratègia consisteix a fer còpies completes diàries, o, el que és el mateix, fer una còpia de nivell zero de dilluns a diumenge. En la seva forma més simple aquesta còpia és:

cd /
tar czpf /copies/home.tgz home

El primer que fem és situar-nos al directori / per evitar posar el símbol / a l’inici dels noms dels fitxers o directoris que volem copiar (l’opció -C de tar també fa aquest servei). A continuació fem una còpia del directori /home empaquetant les dades i comprimint-les en un fitxer anomenat home.tgz i ubicat a /copies. L’opció p és per preservar els atributs de seguretat (propietari, grup i permisos) dels fitxers que copiem. Assumim que /copies és un sistema de fitxers creat en un disc extern.

Afegim aquestes dues línies en un guió de shell que podem ubicar al directori /usr/local/bin i l’anomenem completa.sh. Després planifiquem l’execució d’aquesta tasca perquè s’executi diàriament i triem una hora en la qual no hi hagi activitat en el sistema per dues raons:

• Per garantir la integritat de les dades que es copien.
• Perquè el procés de còpia no afecti al rendiment global del sistema.

La línia del crontab podria quedar així:

0 2 * * */usr/local/bin/completa.sh

Fixeu-vos que si no fem res més, la retenció de les còpies amb aquest sistema és només d’un dia, ja que cada dia estem guardant la còpia completa amb el mateix nom, i, per tant, estem sobreescrivint el fitxer. Generalment voldrem mantenir les còpies de més d’un dia d’antiguitat.

En el nostre cas, podem fer una modificació molt senzilla per mantenir sempre les set darreres còpies realitzades. Consisteix a afegir un número al nom del fitxer que indiqui el dia de la setmana en què es fa la còpia, per exemple:

cd /
tar czpf /copies/home$(date +%u).tgz home

Amb aquesta modificació, el nom del fitxer generat conté el resultat de l’execució de l’ordre date +%u per indicar el dia de la setmana (home1.tgz els dilluns, home2.tgz els dimarts, etc.). Així, cada dia sobreescriurem la còpia de fa una setmana i mantindrem les dels sis dies anteriors.

La segona estratègia consisteix a fer una còpia setmanal completa (per exemple el diumenge) i una còpia de nivell 1 (diferencial) la resta de dies de la setmana. En aquesta estratègia, a la còpia de nivell 0 realitzada el diumenge que implementem com acabem de veure, li hem d’afegir la còpia diferencial diària, que en la seva forma més simple és:

find /home -type f -newer /copies/home0.tgz >/tmp/llista
tar czpTf /tmp/llista /copies/home$(date +%u).tgz

Veiem que ara estem utilitzant l’ordre find per generar una llista de tots aquells fitxers de /home que siguin més nous que el fitxer que conté la còpia completa. En el tar hem afegit l’opció T per llegir els fitxers a copiar des de la llista generada en el pas anterior.

Afegim les dues línies a un shell script que anomenem diferencial.sh i planifiquem la còpia completa perquè s’executi únicament els diumenges i la diferencial perquè s’executi la resta de dies de la setmana. Per exemple:

0 2 * * 0/usr/local/bin/completa.sh
0 2 * * 1-6/usr/local/bin/diferencial.sh

La tercera estratègia consisteix a fer una còpia completa setmanal (per exemple el diumenge) i una incremental la resta de dies de la setmana (nivell 1 el dilluns, nivell 2 el dimarts, nivell 3 el dimecres, etc.). En aquesta estratègia, a la còpia realitzada el diumenge de nivell 0 que implementem com en els altres casos, li hem d’afegir la còpia incremental diària, que en la seva forma més simple és:

find /home -type f -mtime 1 > /tmp/llista
tar czpTf /tmp/llista /copies/home$(date +%u).tgz

En aquest cas estem utilitzant l’ordre find per generar una llista de tots aquells fitxers de /home que s’han modificat en les darreres 24 hores. El tar s’ha d’interpretar igual que en el cas anterior.

De manera anàloga al cas anterior, afegim les dues línies a un guió de shell que anomenem incremental.sh i planifiquem la còpia completa per als diumenges i la incremental per a la resta de dies. Per exemple:

0 2 * * 0/usr/local/bin/completa.sh
0 2 * * 1-6/usr/local/bin/incremental.sh

Podem millorar els procediments per implementar les diferents estratègies de còpia (completa, diferencial i incremental) si en els shell scripts utilitzem variables, afegim control d’errors, etc. A continuació, i a tall d’exemple, veiem una versió millorada del shell script que hem anomenat completa.sh:

#/bin/bash
# completa.sh 
# Còpia completa de dades
#
# Directoris a copiar, no incloem la / inicial
DIRS="etc home var"
# Directori de destinació de la còpia
BACKUPDIR="/copies"
# Nom del fitxer de la còpia
AVUI=$(date +"%Y-%m-%d")
FITXER="completa_$AVUI.tar.gz"
# Nombre de dies per guardar còpies antigues
ANTIGUES=14
#
# Missatge d'inici
echo "$(date +%X) Inici del procediment de còpia."
#
# Comprovació que l'eina tar hi és
TAR=$(which tar)
if [ -z "$TAR" ]; then
  echo "Error: no s'ha trobat tar."
  exit 1
fi
# Comprovació que el directori de còpies hi és
if [ ! -d $BACKUPDIR ] ; then
  echo "Error: no s'ha trobat $BACKUPDIR"
  exit 1
fi
# Fem la còpia
$TAR -zcPf $BACKUPDIR/$FITXER -C / $DIRS
if [ $? -ne 0 ]
then
# El tar ha fallat
  echo "Error: hi ha hagut algun error en fer la còpia."
  exit 1
fi
# Esborrem les còpies anteriors a $ANTIGUES
find $BACKUPDIR/ -name "*.gz" -type f -mtime +$ANTIGUES -delete
if [ $? -ne 0 ]
then
  echo "Error: eliminant les còpies antigues."
  exit 1
fi
# Missatge de finalització
echo "$(date +%X) Final correcte de la còpia."
exit 0

Aquest guió de shell permet guardar tantes copies com s’hagin definit a la variable ANTIGUES. El nom del fitxer de còpia que es genera és: completa_AAA-MM-DD.tar.gz. Per exemple, si fem una còpia el dia 11 de març de 2012 tindrem un fitxer que es dirà completa_2012-03-11.tar.gz.

Planifiquem l’execució diària del guió de shell a l’hora que convingui. Per exemple:

0 2 * * */usr/local/bin/completa.sh

Si volem guardar un registre de l’activitat d’aquest shell script hem de redirigir les sortides estàndard i d’errors a un fitxer. Per exemple:

0 2 * * * /usr/local/bin/completa.sh >>fitxer 2>>fitxer

El fitxer de registre usualment el crearem en el directori de registre del sistema, /var/log. En aquest cas podem crear un directori anomenat /var/log/local i desar allà els fitxers de registre dels procediments de còpia i d’altres procediments locals de manteniment del servidor. Per al guió de shell completa.sh, el nom del fitxer de sortida pot ser /var/log/local/completa.log.

En els sistemes Unix i derivats hi ha un servei anomenat syslog que és l’encarregat d’enregistrar l’activitat del sistema operatiu i de les aplicacions que utilitzen aquest servei, com ara el servei cron (planificació de treballs) o lpr (subsistema d’impressió) entre d’altres.

Generalment, tots els fitxers de registre del sistema, siguin o no gestionats per syslog, se solen emmagatzemar al directori /var/log/. Encara que la majoria de fitxers de registre són de text i els podem veure amb qualsevol editor, en podem trobar algun d’especial que no desi les seves dades en aquest format, com ara els fitxers /var/log/wtmp i /var/log/btmp, que són els registres d’entrada d’usuaris en el sistema i d’entrades errònies respectivament. Per veure aquests dos fitxers, podem utilitzar les ordres last i lastb. Si tinguéssim configurats aquests registres en algun altre fitxer, també els podríem veure passant el paràmetre amb l’ordre last -f nom_fitxer.

Normalment s’utilitza un sistema de rotació de registres, que consisteix a anar comprimint cada cert temps aquests fitxers i a desar-los fins que tinguin una antiguitat determinada. Per exemple, es poden comprimir cada setmana i desar només els d’un o dos mesos anteriors. Segons el servidor que estiguem administrant haurem de tenir en compte la legalitat vigent, que en alguns casos obliga a conservar els fitxers de registre durant un període de temps determinat.

Hi ha programes que ens permeten fer ús del sistema de log que podem utilitzar en els nostres shell scripts per crear els nostres propis fitxers de registre o, si escau, manipular manualment els del sistema: amb logger podem escriure en el syslog del sistema i amb savelog podem desar i opcionalment comprimir els fitxers de registre.

El programa logrotate està dissenyat per facilitar les tasques de gestió de registres. Permet la rotació automàtica, compressió, eliminació i l’enviament per correu dels fitxers. Cada fitxer de registre pot ser tractat diàriament, setmanal, mensual o quan es fa massa gran.

Normalment, logrotate s’executa com una tasca diària de cron. Al directori /etc/cron.daily hi ha un guió de shell anomenat logrotate que conté les línies següents:

#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

El fitxer /etc/logrotate.conf és on es configura el mode d’operació de logrotate. Per defecte té un contingut similar al següent (els comentaris originals són en anglès):

# rotar els fitxers de registre setmanalment
weekly
# mantenir 4 setmanes de fitxers antics 
rotate 4
# crear fitxers nous buits després de rotar
create
# comprimir els fitxers
#compress
# directori on desar fitxers de configuració específica de les aplicacions
include /etc/logrotate.d
# configuració per als serveis wtmp i btmp
/var/log/wtmp {
  missingok
  monthly
  create 0664 root utmp
  rotate 1
}
/var/log/btmp {
  missingok
  monthly
  create 0660 root utmp
  rotate 1
}
# altres logs específics del sistema es poden configurar aquí

Les aplicacions poden deixar els seus propis fitxers al directori /etc/logrotate.d per especificar les seves opcions. Per exemple, el servei CUPS instal·la per defecte aquest fitxer:

/var/log/cups/*log {
  daily
  missingok
  rotate 7
  sharedscripts
  postrotate
    if [ -e /var/run/cups/cupsd.pid ]; then
      invoke-rc.d --quiet cups force-reload > /dev/null
      sleep 10
    fi
  endscript
  compress
  notifempty
  create 640 root lpadmin
}

El programa logrotate ens dóna la possibilitat d’automatitzar la gestió dels fitxers de registre del sistema i de les aplicacions, però la manipulació d’aquests fitxers també es pot fer amb guions de shell creats per nosaltres amb aquest propòsit.

A continuació veiem un exemple senzill per esborrar els registres del fitxer de log del sistema anomenat /var/log/messages. El programa esborra el fitxer i es queda amb 50 línies o les que indiqui l’usuari en la línia d’ordres.

#!/bin/bash
# borralog.sh
# Neteja fitxers de registre del sistema
#
# Definició de variables
LOG_DIR=/var/log
FITXER=messages
ROOT_UID=0
LINIES=50
# Definició de funcions
missatge () {
  DATA=$(date +"%b %x - %X")
  echo "$0: $DATA --> $1"
}
############## Programa principal ##############
# Missatge d'inici
missatge "Inici esborrat de logs."
# Comprovem que som root.
if [ "$UID" -ne "$ROOT_UID" ]; then
  missatge "Error: heu de ser root."
  exit 1
fi
# Establir el nombre de línies que cal preservar
case "$1" in
  "") 
    linies=$LINIES
    ;;
  *[!0-9]*) 
    echo missatge "Error: $1 argument invàlid."
    exit 1
    ;;
  *)
    linies=$1
    ;;
esac
# Canviar al directori de logs
cd /var/log || {
 
  missatge "Error: no puc anar a $LOG_DIR." >&2
  exit 1;
}
# Guardar les línies que volem del fitxer de log
tail -n $linies $FITXER > $FITXER.tmp
mv $FITXER.tmp $FITXER
# Missatge de final
missatge "Final de l'esborrat de logs."
exit 0

El guió de shell anterior pot ser executat de manera interactiva o bé es pot planificar amb cron per ser executat periòdicament. Per exemple:

30 1 * * */usr/loc/bin/borralog.sh 

Si volem guardar el registre de l’activitat d’aquest shell script, hem de redirigir les sortides estàndard i d’errors a un fitxer. Per exemple:

30 1 * * * /usr/local/bin/borralog.sh >>fitxer 2>>fitxer

El nom del fitxer de sortida podria ser: /var/log/local/borralog.log.

Els usuaris dels sistemes de tipus Unix tenen assignat un compte o nom d’usuari que els identifica. Cada compte d’usuari també té una contrasenya que els permet accedir al sistema anomenada clau d’accés (password). A més a més, a Unix cada usuari pertany com a mínim a un grup d’usuaris, que anomenem el seu grup primari o principal. En cas de ser necessari, un usuari pot pertànyer a més d’un grup i en aquest cas es diu que són els seus grups secundaris o addicionals.

Una de les funcions de l’administrador del sistema és donar d’alta els grups i els usuaris al sistema. Hi ha un usuari especial anomenat superusuari o root, que es crea amb la instal·lació del sistema operatiu i disposa dels màxims drets al sistema.

Hi ha moltes eines que permeten fer la gestió d’usuaris i grups des d’una interfície gràfica, per exemple l’eina d’administració Webmin o les interfícies dels escriptoris de GNOME i KDE, entre d’altres. Alternativament, per treballar des de línia d’ordres, en algunes distribucions de Linux, entre d’elles a Debian, hi ha els programes useradd, userdel i usermod per a la gestió d’usuaris, i groupadd, groupdel i groupmod per a la gestió de grups.

La gestió d’usuaris pot donar molta feina tenint en compte que, per exemple, ens podem trobar que volem donar d’alta grups de més de 20 persones. En aquests casos el més habitual és fer guions de shell que permeten automatitzar aquesta tasca i donar d’alta usuaris nous de forma massiva a partir d’un fitxer de text amb un format especial.

A tall d’exemple mostrem un guió de shell que dóna d’alta tots els usuaris descrits en un fitxer de text amb format CSV. Els camps de les línies del fitxer d’usuaris són els següents:

nom_usuari,grup_primari,contrasenya_inicial

Per exemple, si volem donar d’alta la usuària angela i l’usuari david amb grup primari alumnat i contrasenya 123 i 456 respectivament, i l’usuari marius amb grup professorat i contrasenya 789, el fitxer CSV ha de contenir les línies:

angela,alumnat,123
david,alumnat,456
marius,professorat,789

El codi del programa és el següent:

#/bin/bash
# altausu.sh
# Dóna d'alta usuaris a partir de la informació d'un
# fitxer CSV. El format de les línies del fitxer és: 
# nom,grup,contrasenya
#
# Nom del fitxer CSV
FITXER=usuaris.csv
ROOT_UID=0
#
# Comprovacions
if [ "$UID" -ne "$ROOT_UID" ]; then
  echo "Error: heu de ser root."
  exit 1
fi
if [ ! -f "$FITXER" ]; then
  echo "Error: no s'ha trobat $FITXER."
  exit 1
fi
# Inici del procés
for linia in $(cat $FITXER); do
  echo $linia
  USUARI=$(echo $linia | cut -f1 -d",")
  GRUP=$(echo $linia | cut -f2 -d",")
  PASSWD=$(echo $linia | cut -f3 -d",")
  echo "Creant l'usuari $USUARI..."
  /usr/sbin/useradd -m -g $GRUP $USUARI
  echo "Assignant contrasenya a $USUARI..."
  echo "$USUARI:$PASSWD" | chpasswd
done

Aquest shell script automatitza i simplifica considerablement la tasca de creació d’usuaris. Podem millorar el codi del programa afegint, si cal, el tractament de més camps del fitxer d’informació d’usuaris (directori de treball, shell d’inici, etc.), fent control d’errors, guardant els missatges de sortida en un fitxer de registre, etc.

Durant el procés d’arrencada del sistema s’inicien els processos que anomenem dimonis (daemons en anglès). Generalment tots els dimonis tenen un guió de shell situat al directori /etc/init.d/ que ens permet iniciar-los, aturar-los o veure el seu estat d’execució. La majoria d’aquests scripts utilitzen un programa anomenat start-stop-daemon que ens proporciona el sistema operatiu i que serveix per al tractament d’aquests processos.

En administrar un servidor es pot donar el cas que ens haguem de dissenyar els nostres propis dimonis per fer alguna tasca concreta. Al directori on se situen tots els guions de shell dels dimonis, se’n sol trobar un d’exemple anomenat /etc/init.d/skeleton perquè el puguem utilitzar quan en necessitem configurar un de nou. El codi del dimoni d’exemple és similar al següent:

#!/bin/sh 
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin: /usr/sbin:/usr/bin DAEMON=/usr/sbin/daemon 
NAME=daemon 
DESC="some daemon" 
test -x $DAEMON || exit 0 
set -e
case "$1" in 
  start) 
    echo -n "Starting $DESC: $NAME" 
    start-stop-daemon --start --quiet --pidfile \ 
    /var/run/$NAME.pid --exec $DAEMON echo "." 
    ;; 
  stop) 
    echo -n "Stopping $DESC: $NAME "
    start-stop-daemon --stop --quiet --pidfile \ 
    /var/run/$NAME.pid --exec $DAEMON echo "." 
    ;; 
  restart|force-reload) 
    echo -n "Restarting $DESC: $NAME" 
    start-stop-daemon --stop --quiet --pidfile \ 
    /var/run/$NAME.pid --exec $DAEMON 
    sleep 1 
    start-stop-daemon --start --quiet --pidfile \ 
    /var/run/$NAME.pid --exec $DAEMON echo "." 
    ;; 
  *) 
    N=/etc/init.d/$NAME echo " Usage: $N {start|stop| \
    restart|force-reload}" >&2 
    exit 1 
    ;; 
esac 
exit 0

La primera línia indica quin és el shell d’execució. Gairebé en tots els scripts d’inici trobarem el shell /bin/sh. Com que Bash és compatible amb sh, les ordres i els programes escrits per a sh poden ser executats amb Bash sense cap modificació. Però al revés no és cert. Per tant, si necessitem escriure un shell d’inici amb característiques específiques del llenguatge Bash hem de canviar la primera línia i posar /bin/bash.

En les variables declarades a l’inici del guió de shell especifiquem quin PATH és necessari per al procés del dimoni, el programa que executarem (DAEMON), el nom que li donem (NAME), que ha de ser igual que el nom del shell script, i la descripció (DESC).

En arrencar el dimoni la única cosa que fem és escriure al directori /var/run/ un fitxer amb el PID del procés. En aturar-lo, es buscarà aquest PID i s’enviarà el senyal d’acabament al procés corresponent.

Trobarem guions de shell preparats per a fer moltes més operacions amb el nostre dimoni, però, com a mínim, tots han de tenir aquesta estructura.