Robins blogg

Ni känner säker igen det. Man skriver ett skript som gör nåt nyttigt, men en dag fallerar det och det tar en massa tid att stöda upp efter allt skriptet gjorde efter det fallerade.

För att skriva mera tillförlitliga bash-skript utan att ha överdrivet mycket felkontroller kan man använda en option som automatiskt avslutar skript vid fel. Då slipper man skript som går vidare och saboterar en massa data när nåt kommando går fel. Flaggan heter ‘-e’ och kan läggas på första raden i bash-skript eller senare, då med kommandot set -e

#!/bin/bash -e
trap 'echo "***error**"' 0

tar cvfz /tmpdir/arkiv.tgz *
rm -rf *

# Stäng av felhanteringen just före vi avslutar
trap 0

I detta exempel kopierar vi först en massa filer och raderar dem sedan. Men om arkivet inte går att skapa så vill vi naturligvis inte radera allt. Med felkontroll på allt blir skripten säkrare. Utan -e skulle skriptet radera allt och tyvärr är det så många skript gör eftersom det är så jobbigt att lägga in felkontroller. I ett stabilt skript är en stor del av koden explicita felkontroller. Trap-kommandot är ett inbyggt kommando som fångar signaler, man signal(2), men även några anda händelser, t.ex. när skript avslutas vilket vi är intresserade av här för att få ut ett felmeddelande när nåt går fel.

Sen inträffar det förstås att kommandon kan ge en felkod utan att man vill terminera direkt. Det kan finnas en alternativ väg eller så vill man anpassa felmneddelandet. Om kommandot är ett villkor i en if-sats bryts inte skriptet om kommandot går fel utan if-satsen får ta hand om felkoden.

#!/bin/bash -e
trap 'echo "***error**"' 0

if ! tar cvfz /tmpdir/arkiv.tgz *
then
 tar cvfj /tmpdir/arkiv.tar.bz2 *
fi
rm -rf *

# Stäng av felhanteringen just före vi avslutar
trap 0

I detta fall provar vi att komprimera hårdare (ifall disken inte räckte till för vanlig gzip. Om bzip2-komprimeringen misslyckas terminerar skriptet.

I slutändan hamnar man på att skriva ungefär like mycket felhanteringskod med -e, främst för att få fram bra felmeddelanden, men de tidiga versionerna, där logiken är vikitigast, kommer att vara mycket mer robusta och lättare att felsöka.

För att initiera CVS-arkiv finns en import-funktion. Man måste dock inte använda det bara för att spara källkod. Man kan använda det för backup också eller för att spåra konfigurationsändringar och se när de skett. När jag säger konfigurationsändringar är det /etc jag tänker på.

Skapa arkivet med cvs -d /arkivkatalog init

Skapa seden ett skript att köra varje dag. Med vixie cron kan du helt enkelt skapa filen med följande namn
/etc/cron.daily/etcbackupviacvs och detta innehåll:

#!/bin/bash
cd /etc
cvs -d /arkivkatalog -Q import -m backup myhost/etc backup backup$(date +%Y%m%d%H%M)

Glöm inte att chmodda den med chmod +x /etc/cron.daily/etcbackupviacvs

Kör skriptet en gång och skapa initialkonfigurationen.

Om nåt slutar fungera eller om man undrar vad nån wizard gjort, kan man titta i CVS och se vad som ändrats. Ex.Vad
har hänt i brandväggsskonfigen när jag senast ändrade konfigurationen. Kör först cronjobbet manuellt genom att köra
skriptet ovan (eller vänta till cron drar igång jobbet).

# cvs -d /arkivkatalogl/backupcvs rdiff -u -r backup200602150200 -r backup200602161800 myhost/etc/shorewall
cvs rdiff: Diffing myhost/etc/shorewall
Index: myhost/etc/shorewall/interfaces
diff -u myhost/etc/shorewall/interfaces:1.1.1.2 myhost/etc/shorewall/interfaces:1.1.1.3
--- myhost/etc/shorewall/interfaces:1.1.1.2    Wed Jan 25 23:19:01 2006
+++ myhost/etc/shorewall/interfaces    Thu Feb 16 22:20:24 2006
@@ -193,5 +193,4 @@
 #
 net    eth0    detect
 loc    eth1    detect
-loc    tap2    detect
 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Ajdå. Mandrivas wizard såg inte OpenVPN’s nätverksgränssnitt som inte var aktivt när wizarde kördes. Visserligen varnade den, men den sade inte vad som var problemet.

Min 60GB:ar rasade. Det syntes som att jag inte hade några extended-partitioner längre. Med smartmontools kunde man se att det fanns fel på disken, liksom i /var/log/messages.

Här är stegen aningen förenklat för att återställa.

• Kopiera disken.
  
  Det är ingen idé att försöka laga innehållet på en trasig disk. Det som händer är att man trasar datat ännu mera eller t.om. slutgiltigt. Jag genom att boota maskinen med Mandrake Move (Knoppix funkar också) och kopiera disken till en annan disk, i detta fall till en annan maskin via ssh. En FireWire/USB-disk är ett alternativ (min maskin var en laptop så en annan intern disk var inget alternativ).
  dd if=/dev/hda bs=512 conv=noerror,sync | ssh robin@kivi cat \>xine.hda
  
  Det här tar tid med ett normalt nätverk. 60GB / 100Mb = ~ 2 timmar.
• Skanna disken efter partitioner.
  
  gpart söker efter sånt som ser ut som partitioner.
  losetup /dev/loop0 xine.hda
gpart -f -g -v /dev/loop0

  
  Bland det intresanta (råkar veta att storleken verkar rätt)
  
  

  Possible partition(SGI XFS filesystem), size(9528mb), offset(47692mb)
     type: 131(0x83)(Linux ext2 filesystem)
     size: 9528mb #s(19514496) s(97675263-117189758)
     chs:  (1023/255/0)-(1023/255/0)d (0/0/0)-(0/0/0)r
     hex:  00 FF C0 FF 83 FF C0 FF FF 67 D2 05 80 C4 29 01
  

  
  Man får en hel del falska tips om partitioner. Det är inte så mycket att oroa sig för mera än att det tar tid att prova alla, men det kan man undvika om man
  har en aning om hur stora partitioner man hade.

• Montera partitioner

Startsektorn * 512 (blockstorlek) ger offset till partitionen. Gör om losetup
med offset.

 losetup -d /dev/loop0
 losetup -o $((97675263*512)) /dev/loop0 xine.hda

Nu kan man (skall kunna) montera filsystemet med

mount /dev/loop0 /mnt/cdrom

Är man orolig kan man prova detta istället

mount -t xfs /dev/loop0 /mnt/cdrom -o ro,norecovery

Nu kan man komma åt innehållet som vanligt.

ls /mn/cdrom

Skall man skriva if [[ "$x" = foo ]] eller if [ "$x" = foo ] i shell-skript? Båda funkar ju lika bra så det är ingen skillnad.

Eller …
(more…)