Tilbake til bloggen
Guide3. mars 2026

Linux: Debian-administrasjon, virtualisering og shell-verktøy

Jeg har brukt Linux siden 2021 — ikke som et eksperiment, men som arbeidsverktøy. Det startet med en Debian-VM i VirtualBox fordi jeg ville forstå hva som faktisk skjedde under panseret når jeg deployet ting til skyen. Siden den gang har Linux blitt en fast del av verktøykassen min. Jeg administrerer Debian-servere, kjører virtualiseringsmiljøer, og har bygd et shell-oppsett som gjør meg raskere i terminalen enn noen GUI kunne gjort.

Dette innlegget er ikke en "Linux for beginners"-guide. Det handler om hvordan jeg faktisk bruker Linux i hverdagen — fra VMware ESX til Zsh-konfigurasjon.

Debian som fundament

Jeg valgte Debian av én grunn: stabilitet. Ikke fordi det er det mest spennende valget, men fordi servere som kjører 24/7 trenger forutsigbarhet. Debian Stable gjør nøyaktig det — pakkene er grundig testet, oppdateringer bryter sjelden noe, og community-et er enormt.

For lokal utvikling og eksperimentering bruker jeg Debian Bookworm (12). For servere som kjører tjenester bruker jeg det samme. Konsistens mellom utvikling og produksjon er like viktig her som det er med Docker.

Pakkehåndtering er grunnleggende, men det er verdt å nevne apt sin styrke: apt update && apt upgrade -y holder systemet oppdatert. apt autoremove fjerner pakker som ikke lenger trengs. For mer kontroll bruker jeg apt-mark hold <pakke> for å forhindre at kritiske pakker oppdateres automatisk.

Virtualiseringsstack

Jeg har jobbet med tre forskjellige virtualiseringsplattformer, hver med sitt bruksområde:

VMware ESXi for tyngre produksjonslignende oppsett. Jeg har brukt det til å sette opp flermaskinsnettverk der jeg kan simulere en realistisk infrastruktur — webserver, database, og reverse proxy på separate VMer som kommuniserer over et internt nettverk.

VirtualBox for rask lokal testing. Når jeg trenger å teste et script på en ren Debian-installasjon, spinner jeg opp en VM på minutter. Snapshots gjør det enkelt å eksperimentere uten risiko.

UTM på macOS for ARM-basert virtualisering. Etter at jeg byttet til Apple Silicon, ble UTM løsningen for å kjøre Linux lokalt med god ytelse.

Zsh-oppsett som fungerer

Jeg byttet fra Bash til Zsh for flere år siden, og har aldri sett tilbake. Ikke på grunn av hype, men fordi autokomplettering, plugin-systemet og prompt-konfigurasjonen gjør hverdagen i terminalen merkbart bedre.

Her er kjernen av .zshrc-oppsettet mitt:

export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME="agnoster"

plugins=(
  git
  zsh-autosuggestions
  zsh-syntax-highlighting
  docker
  kubectl
)

source $ZSH/oh-my-zsh.sh

alias ll="ls -lah"
alias gs="git status -sb"
alias dc="docker compose"
alias k="kubectl"
alias update="sudo apt update && sudo apt upgrade -y"

export EDITOR="nvim"
export PATH="$HOME/go/bin:$HOME/.local/bin:$PATH"

zsh-autosuggestions foreslår kommandoer basert på historikken — det sparer enormt med tastetrykk. zsh-syntax-highlighting farger kommandoen rød hvis den ikke finnes, og grønn hvis den gjør det. Små ting som til sammen utgjør en stor forskjell.

SSH-konfigurasjon for flere miljøer

Når du administrerer flere servere og tjenester, er en god ~/.ssh/config essensielt. Istedenfor å huske IP-adresser og brukernavn, definerer jeg alt én gang:

Host dev-server
  HostName 192.168.1.100
  User ryan
  IdentityFile ~/.ssh/id_ed25519
  ForwardAgent yes

Host prod-db
  HostName db.example.com
  User admin
  IdentityFile ~/.ssh/id_ed25519_prod
  Port 2222

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github

Nå er det bare ssh dev-server — ingen parametere, ingen ting å huske. ForwardAgent yes er nyttig når jeg trenger å bruke min lokale SSH-nøkkel fra serveren, for eksempel for å klone private repos.

Jeg bruker utelukkende Ed25519-nøkler. De er kortere, raskere, og mer sikre enn RSA. Generering er enkelt: ssh-keygen -t ed25519 -C "ryan@server".

Systemd for tjenestehåndtering

Når jeg kjører egne tjenester på en server, bruker jeg systemd for å sikre at de starter automatisk og restarter ved feil:

[Unit]
Description=Tuli API Server
After=network.target postgresql.service

[Service]
Type=simple
User=tuli
WorkingDirectory=/opt/tuli
ExecStart=/opt/tuli/server
Restart=on-failure
RestartSec=5
Environment=DATABASE_URL=postgres://tuli:secret@localhost:5432/tuli

[Install]
WantedBy=multi-user.target

After=network.target postgresql.service sørger for at nettverket og databasen er klare før tjenesten starter. Restart=on-failure med RestartSec=5 betyr at systemd prøver igjen etter 5 sekunder hvis prosessen krasjer. Enkelt, pålitelig, og innebygd i systemet.

Ting jeg har lært

Automatiser alt du gjør mer enn tre ganger. Bash-scripts for backup, oppdateringer og deployment sparer timer over tid.

Hold systemet minimalt. Installer bare det du trenger. Færre pakker betyr færre sikkerhetshull og enklere vedlikehold.

Lær `journalctl`. Systemd-logger er gull verdt for feilsøking. journalctl -u tuli-api -f følger loggene i sanntid. journalctl --since "1 hour ago" viser alt som har skjedd den siste timen.

Forstå filrettigheter. chmod og chown er ikke bare kommandoer du kopierer fra StackOverflow. Forstå oktalnotasjonen (755, 644) og hva det betyr for sikkerhet.

Oppsummering

Linux er ikke bare et operativsystem for meg — det er et verktøy jeg administrerer og vedlikeholder aktivt. Debian gir stabilitet, virtualisering gir fleksibilitet, og et godt shell-oppsett gjør hverdagen effektiv. Kombinasjonen av disse gjør at jeg forstår hele stacken fra maskinvare til applikasjon.

#linux#debian#vmware#shell

Nyhetsbrev

Få nye innlegg rett i innboksen.