Göm menyn

TDDI41 Grundläggande systemadministration

Labb SCT: Skriptande och 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, trots 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. För att lägga till en användare gör du t ex så här: 

import subprocess
username = 'testuser'
subprocess.run(['useradd', '-m', username])
jämfört med bashs 
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).

Shebang - [SCT.1]

Vad är en shebang? Och hur används det?

Inlämning: Svar på frågor.

Python

Vi har en rad länktips om du besöker sidan för kurslitteratur.

Val av språk

Bra att veta: Bash och Python får användas. Övriga programmeringsspråk kan godkännas efter rådslagning med laborationsassistent.

Automatisering

Skript för att automatiskt skapa användarkonto - [SCT.2]

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

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(8) (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. Det är OK att använda echo här. Vi antar här att skriptet bara kommer att köras på ett system där ingen obehörig är inloggad (servern, i senare labbar).

Inlämning: Skripet ska lämnas in, men innan inlämning rekommenderas det starkt att ni demonstrerar skriptet för en kursassistent. Ni kommer bes köra med en fil, och sedan logga in på en av de nyskapta användarna (förslagsvis via ssh). Syftet med att demonstrera är så att vi redan nu kan fånga eventuella problem. I senare labbar kommer ni att utöka detta skript, så det är viktigt att grunden är korrekt.

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äsrä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.

Skript för automatiserad testning - [SCT.3]

Skriv två automatiserade tester med hjälp av skript:

  • 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). En lista över de skal som är giltiga finns i /etc/shell (använd den dynamiskt; hårdkoda alltså inte)
Båda testfallen kan ligga i samma skriptfil. Ha dem inte i användarskapar-skriptet.

Inlämning: Skriptfil med förklaring.

Framöver 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: Daniel de Leng
Senast uppdaterad: 2025-08-12