Göm menyn

TDDI41 Grundläggande systemadministration

Skriptande & testande

Stunden man vill göra saker mer än en gång brukar det vara värt att automatisera dem.

Två av de vanligaste programmeringsspråken för skript är Bash och Python. Bash är det klasiska i Unix-världen (och det ni troligen kör som skal). Det är ytterst kraftfullt, men väldigt lätt att skjuta sig själv i foten med. Ett typexempel är att Bash hanterar alla odefinierade variabler som tomma strängar, så någonting halvoskylldigt som 

rm -r $PROGRAM_PATH/$SUBDIR
blir (när båda variablerna är odefinierade): 
rm -r /
vilket tar bort precis allting på ens system om det körs som root.

Python, trotts visa brister, är en bra bit mer robust. Språket har riktiga typer (och låtsas inte att allting är strängar), funktioner specificerar hur många och vilka argument de tar, med mera. Det är dock aningen klumpigare att köra systemkommandon (som ingen slagit in i pythonfunktioner redan) från det. T.ex. för att lägga till en användare: 

import subprocess
username = 'testuser'
subprocess.run(['useradd', '-m', username])
jämfört med bash's 
username=testuser
useradd -m $username

Bash

Om man vill läsa mer om Bash är dess info-sidor bra (Vilka finns online här).

Kommandot set -x skriver ut allting som körs, vilket kan vara till stor hjälp (Mer info finns i manualen).

Python

Pythons officiella dokumentation är bra Se till att ni har rätt version (3 och inte 2). Inbyggt i Python finns funktionen help, vilken kan köras på godtyckligt annat objekt Learn X in Y minutes har en snabbgenomgång i Python, för de som redan kan programmera (i liknande språk).
Vad är en shebang?

Bash, Python & Perl får alla användas utan vidare.

Övriga programmeringsspråk kan godkännas efter rådslagning med laborationsassistent.

Automatisering

Skriv ett program vilket som första argument får en lista över personers namn, ett per rad, och skapar användarkontot på ert system för var och en av dem.

Så här ska det anropas (filnamnet kan såklart variera!)

$ ./generate_accounts names-tricky

Redovisning: Skripet ska lämnas in, innan inlämning ska ni demonstrera det för en labass. Ni kommer bes köra med en fil, och sedan logga in på en av de nyskapta användarna (förslagsvis via ssh).

Skriptet ska uppfylla följande (som också kan ge en hint om arbetsflödet)
  1. Generera ett unikt användarnamn i stil med LiU-ID (helst baserat på personens riktiga namn, och slumpade siffror/bokstäver). Av kompatibilitetsskäl, måste användarnamnen följa rekommendationen i man-sidan för useradd (sök på "Usernames may only")! Om det verkligen inte går att utgå från användarens namn, är det OK att slumpa.
  2. Lägg till användaren på systemet.
  3. Se till att användaren har en hemkatalog, med eventuella standardfiler i (lista också ut varifrån dessa kommer!)

  4. Slumpa fram och sätt ett lösenord.

    Eftersom alla i systemet kan se viss information om körande processer, får ni får inte starta processer med lösenordet som argument. Inga echo HEMLIGTLÖSENORD | <något> alltså! Den uppmärksamme kan se att echo-rogrammet startat, med HEMLIGTLÖSENORD som argument. Pipes är däremot helt OK!

  5. Skriv ut användarnamn och lösenord
I senare labbar kommer ni att utöka detta skript.

Bland annat kommer useradd, iconv (och "teckenkodningen" "ASCII//TRANSLIT") och chpasswd vara er till hjälp

Testfilerna /courses/TDDI41/names-* finns att tillgå (alltså de UTAN användarnamn). names-tricky går igenom de flesta hopplösa fall.

Testning

Testning är en formell aktivitet som ingår i nästan alla tekniska discipliner. Det utförs vanligtvis för att avslöja brister eller för att visa att de uppfyller specifika krav.

I kursen kommmer ni skriva (genom kod) automatiserade tester för ert system. Det för att säkerställa att tidigare delar av systemet inte går sönder när senare delar ändras, samt för att snabbt hitta felet när någonting går sönder.

Testfall

Testning baseras på testfall. Ett testfall är ett förfarande som kontrollerar om någon egenskap hos ett system finns. Bra testfall har:

  • ett klart definierat och vanligtvis ganska specifikt syfte,
  • ett entydigt och upprepbart förfarande för att genomföra det samt
  • ett entydigt och upprepbart förfarande för tolkning av resultaten.

En stor utmaning i testning är att identifiera vad är de krav som ska testats samt vad är rimliga testfall. Vi kan titta på följande krav exempel:

Exportera /export/files till alla klienter med NFSv4, enbart med läs rättigheter och inga särskilda rättigheter för root.
Här ser vi att det finns ett antal olika krav som vi vill testa.
  • Katalogen /export/files måste existera
  • Vi ska exportera med NFSv4
  • Katalogen ska exporteras till alla klienter
  • Filerna ska vara läsbara men inte skrivbara på klienterna
  • Root användaren på klienterna ska inte ha några andra rättigheter än andra användare
Varje enskilt krav leder sen till ett eller flera testfall, för att kunna verifiera att systemet fungerar som önskat.

Automatiserade tester

I kursen måste du testa allt du gör med hjälp av automatiserade tester. Automatiserade tester är skrivna i kod (t.ex. Python, Bash eller Perl) vilka enkelt kan köras upprepade gånger.

Till Python finns det ett flertal olika test-ramverk. Ett av de populäraste är pyttest. Du kan läsa mer om hur du skriver tester i Python i Getting started With Testing in Python samt Testing your Code on The Hitchhikers Guide to Python.

Filen testsuite.py ger er ett exempel på hur ni kan skriva era testfall.

Under kursen kan du uppmanas att köra dina tester, så förbered dem när du jobbar med dina uppgifter. Detta så vi enklare kan hjälpa dig identifiera eventuella problem.

Skriv två automatiserade tester (script) :
  • Ett testfall som verifierar att det existerar en användare root
  • Ett testfall som verifierar att användaren games inte har något giltigt skal (noshell)
Era testfall kan ligga i samma script-fil.

Under projektdelarna (lab 5 och framåt) kommer det finnas krav på testning av olika komponenter. Ni uppmuntras (starkt) att skriva testerna för varje individuell del omedelbart efter implementation, för att säkerställa att vidare konfiguration inte har sönder tidigare.

Testfallen kommer, utöver att vara ett krav för varje labb, även vara en del av er slutredovisning.


Sidansvarig: Anders Fröberg
Senast uppdaterad: 2023-12-11