TDDI41 Grundläggande systemadministration

Eventuell changelog finns längst ned på sidan

OBS! Som alltid, följ de allmänna instruktionerna kring inlämning, och kopiera in vad ni gjorde och utdata. Se exempel på sidan.

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, 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 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

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

---

Automatisering

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:

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.

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.

Changelog innevarande termin

• 241111: Flyttat Python-länkarna till Lästips-sidan.
• 241111: Förtydligat att testerna inte bör ligga i användarskaparskriptet. Har ni redovisat detta innan detta datum behöver det inte kompletteras.
• 241111: Förtydligat att giltiga skal listas i /etc/shell. Har ni redovisat detta innan detta datum behöver det inte kompletteras.

Sidansvarig: Anders Fröberg
Senast uppdaterad: 2024-12-12