SSH for WordPress-utviklere: 10 kommandoer som vil redde livet ditt

Som WordPress-utvikler bruker du sannsynligvis mye tid i en FTP-klient (FileZilla). Det er en feil. Det som tar 15 minutter i FTP (f.eks. slette en cache-mappe med 100 000 filer), tar 2 sekunder i SSH-terminalen.

I denne guiden viser jeg deg et sett med kommandoer som seniorutviklere ikke kan leve uten.

#Hvordan sette opp SSH-innlogging med nøkkel i stedet for passord

Alt under forutsetter at du allerede er inne på serveren, og måten du kommer inn på avgjør om du faktisk kommer til å bruke noe av dette. Et passordspørsmål ved hver eneste tilkobling er akkurat nok friksjon til å sende deg tilbake til FTP-klienten. Lag et nøkkelpar med ssh-keygen -t ed25519, send den offentlige delen med ssh-copy-id user@server, og innloggingen blir ett ord. Lag én nøkkel per maskin i stedet for å kopiere den samme rundt mellom laptop, hjemmemaskin og byggeserver. Det koster ingenting ekstra og gir deg noe du trenger den dagen en maskin forsvinner: du fjerner én linje fra ~/.ssh/authorized_keys på serveren, og akkurat den maskinen er ute, mens alle de andre fortsetter å virke. Deler flere personer på samme driftsbruker, er det også den eneste måten å se hvem som faktisk har tilgang.

#Hvordan lagre innloggingsdata for servere i ~/.ssh/config

Skriver du ssh -p 2222 -i ~/.ssh/kunde_ed25519 [email protected] hver gang, blander du før eller siden porter og nøkler mellom kunder. OpenSSH-klienten leser en fil per bruker, ~/.ssh/config, der hver server får et kort navn (ssh_config(5)):

Host kunde-prod
    HostName s123.hosting.example
    User kunde
    Port 2222
    IdentityFile ~/.ssh/kunde_ed25519
    IdentitiesOnly yes

Fra da av bruker ssh kunde-prod, scp, sftp og rsync disse verdiene av seg selv. Host gjelder for alle linjene under til neste Host- eller Match-blokk, HostName er den egentlige serveradressen, og Port overstyrer standardporten 22. De fleste overraskelser forklares av én regel i dokumentasjonen: for hver innstilling gjelder den første verdien som blir funnet, og ssh leser først valgene på kommandolinjen, deretter brukerfilen og til slutt systemets /etc/ssh/ssh_config. Konkrete verter hører derfor hjemme øverst i filen, og den generelle blokken Host * nederst. På macOS legger GitHubs veiledning for SSH-nøkler til AddKeysToAgent yes og UseKeychain yes i samme blokk, slik at du skriver passfrasen til nøkkelen én gang og den blir liggende i systemets nøkkelring (GitHub Docs).

#Hvordan fikse SSH-feilen too many authentication failures

Meldingen Too many authentication failures rammer som regel dem som har nøkler til mange servere. Klienten tilbyr serveren hver nøkkel ssh-agent har, én etter én, og serveren teller hvert avviste forsøk. Grensen settes av serverinnstillingen MaxAuthTries og er 6 som standard (sshd_config(5)). Ligger riktig nøkkel lenger bak enn plass seks i agenten, stenger serveren forbindelsen før den ser den. Løsningen står i blokken fra forrige avsnitt: IdentitiesOnly yes får ssh til å bruke bare den konfigurerte nøkkelen, selv om agenten tilbyr flere (ssh_config(5)). For en enkelt test holder ssh -o IdentitiesOnly=yes -i ~/.ssh/kunde_ed25519 [email protected], og ssh -v viser i linjene Offering public key hvilke nøkler som faktisk gikk til serveren.

Fra samme familie kommer økten som fryser på en ustabil forbindelse. ServerAliveInterval 15 i vertsblokken får klienten til å be serveren om svar hvert 15. sekund gjennom den krypterte kanalen. Med standardverdien 3 for ServerAliveCountMax kobler ssh ifølge dokumentasjonen fra etter omtrent 45 sekunder uten svar, i stedet for å bli hengende med en frossen terminal.

#1. Hvordan sjekke hva som bruker diskplass på serveren

Når webhotellet roper “Quota Exceeded”, hjelper ikke FileZilla. Bruk dette:

#du (disk usage)

## Vis mapper i nåværende katalog, sortert etter størrelse
du -h --max-depth=1 | sort -hr

#ncdu (ncurses disk usage)

Hvis du kan, kjør ncdu. Det er en interaktiv manager du navigerer med piltastene. På en travel server er det første steget å se hva som fyller disken før du sletter caches og logger. du bruker du når du trenger et tall å lime inn i en sak, ncdu når du ennå ikke vet hva du leter etter. Begge går gjennom hele katalogtreet, og det er ikke gratis: på en stor uploads-katalog holder de disken opptatt i et minutt, og på delt webhotell merkes det som tregere sidevisninger mens de kjører. Pek dem mot en underkatalog i stedet for hjemmekatalogen hvis nettstedet har trafikk. Ingen av dem sier noe om hva du trygt kan fjerne, og på en WordPress-installasjon er den vanligste overraskelsen ikke bilder i det hele tatt, men en node_modules-katalog som ble liggende igjen i temaet etter et byggesteg og som aldri hadde noe på serveren å gjøre.

#2. Hvordan se WordPress debug.log i sanntid

I stedet for å laste ned debug.log, åpne den i Notisblokk og lete etter feil… se den live!

#tail -f

## Følg de siste linjene i filen i sanntid
tail -f wp-content/debug.log

Oppdater nå siden i nettleseren, og feilene vil dukke opp på skjermen. Avslutt med Ctrl+C. Å lese loggen direkte er riktig så lenge du kan utløse feilen på kommando. Klarer du ikke det, har linjen du er ute etter for lengst rullet forbi, og da begynner du heller med tail -n 200 wp-content/debug.log og leser bakover. tail -f tar flere filer samtidig, så tail -f wp-content/debug.log /var/log/nginx/error.log viser deg PHP-feilen og webserverens versjon av samme hendelse ved siden av hverandre, med filnavn som skillelinje. To ting lurer folk her. Filen finnes bare når WP_DEBUG_LOG er slått på i wp-config.php, så et tomt vindu betyr som regel at logging er av, ikke at nettstedet er friskt. Og ingenting roterer filen av seg selv, så et nettsted som kaster en advarsel ved hvert kall skriver seg selv full disk over tid.

#3. Hvordan finne kode i WordPress-filer med grep

Leter du etter hvor add_image_size ble brukt? Ikke last ned hele prosjektet.

#grep

## Søk etter frasen "add_image_size" i alle PHP-filer rekursivt
grep -r "add_image_size" .

Den fulle formen bruker du når du vil lese koden rundt treffet, grep -rl når du bare vil vite hvilken utvidelse som eier en oppførsel. I et tema koster det nesten ingenting, i wp-content/plugins koster det en del, fordi rekursjonen går inn i hver eneste vendor-katalog den finner. --include='*.php' og --exclude-dir=node_modules er de to tilleggene som betaler seg umiddelbart. Bekreft et treff ved å åpne filen på det stedet, ikke ved å telle antall treff: det samme funksjonsnavnet står i utvidelsens egen kode, i dokumentasjonsblokken over den og i oversettelsesfilen, og bare ett av de tre stedene er definisjonen.

#4. Hvordan fikse 403 forbidden med riktige filrettigheter

Ofte etter migrering har filer feil rettigheter. Husk regelen:

• Mapper: 755
• Filer: 644

#find + chmod

Ikke gjør det manuelt. Automatiser det:

## Sett 755 for alle mapper
find . -type d -exec chmod 755 {} \;

## Sett 644 for alle filer
find . -type f -exec chmod 644 {} \;

Kjør dette når du har et symptom, en 403 eller en opplasting som feiler, ikke som rutinevedlikehold. En chmod over hele treet jevner ut hvert bevisste unntak på installasjonen, og det viktigste av dem er wp-config.php: den bærer databasepassordet og hører hjemme på 640 eller strammere, ikke på de 644 løkken nettopp ga den. Løkken rører dessuten bare filer din egen bruker eier, så på et webhotell der webserveren kjører som en annen konto kan den fikse ingenting uten å melde fra om det. Kontroller med ls -l wp-config.php og ved å laste siden som ikke virket, aldri ved å kjøre den samme kommandoen en gang til.

#5. Hvordan ta backup av WordPress med tar over SSH

Vil du ha en rask backup før oppdatering? Ikke kopier via FTP. Pakk det på serveren.

#tar

## Lag arkiv backup.tar.gz av nåværende katalog
tar -czf backup.tar.gz .

Utpakking:

tar -xzf backup.tar.gz

Å pakke på serveren er riktig trekk før en oppdatering, fordi arkivet aldri går gjennom linjen din. Det er likevel ingen sikkerhetskopistrategi: filen ligger på samme disk som nettstedet, så den overlever en mislykket oppdatering, men ikke at disken ryker. Legg til --exclude='wp-content/cache' med mindre du vil arkivere nøyaktig det du straks skal slette. Og se inn i den med tar -tzf backup.tar.gz | head før du stoler på den, for et arkiv som ble kuttet av en full disk ser ut som en helt vanlig fil i katalogen.

#6. Hvordan eksportere og importere WordPress-databasen med WP-CLI

Har du WP-CLI på serveren, og det bør du ha, trenger du ikke phpMyAdmin. Ingen eksport som ryker på tidsavbrudd i nettleseren, ingen opplastingsgrense ved import.

## Eksporter databasen
wp db export backup.sql

## Importer databasen
wp db import backup.sql

## Tøm databasen (vær forsiktig!)
wp db reset

Dumpen skrives til serverdisken, ikke gjennom linjen din. På en nettbutikk som har gått noen år er det forskjellen mellom en eksport på sekunder og en nettleser som gir opp midt i wp_postmeta. WP-CLI kjører som din skallbruker og ikke gjennom webserveren, så opplastingsgrenser og max_execution_time slutter å gjelde. Det den ikke kan overse, er at nettstedet er i drift: wp db import slipper tabellene og bygger dem opp igjen mens noen står i kassen, så et vedlikeholdsvindu er en del av kommandoen og ikke et tillegg. Resultatet sjekker du med en enkelt wp option get siteurl, som feiler høyt og med en gang dersom importen bare kom halvveis.

#7. Hvordan slette en stor cache-mappe raskt via SSH

Å slette en cache-mappe med en million små filer over FTP kan ta en time, fordi FTP kvitterer for hver eneste fil.

#rm

## Slett mappen og alt i den (ingen angremulighet!)
rm -rf wp-content/cache/

Tidsbruk: et halvt sekund. Det finnes ingen papirkurv. Ikke skriv stien fra hukommelsen, bruk tabulator til å fullføre den, så blir ikke wp-content/cache/ til wp-content/. Dette er riktig verktøy for en cache-katalog og nesten aldri riktig for noe annet, siden det verken spør først eller lar seg angre etterpå. Vanen som redder deg er å kjøre ls mot nøyaktig samme sti først, og slette først når listen stemmer med det du hadde i hodet. Se særlig på slutten av stien, for et feilplassert mellomrom gjør ett mål om til to, og det andre er som regel katalogen over. På et nettsted med trafikk bygger utvidelsen cachen opp igjen ved neste forespørsel, så prisen er én treg sidelasting, ikke nedetid.

#8. Hvordan synkronisere WordPress-filer med rsync

FTP laster opp alt på nytt hver gang. rsync sammenligner de to sidene først og sender bare differansen.

#rsync

## Tørrkjør først: vis hva som ville blitt kopiert, endre ingenting
rsync -avzn --exclude 'cache/' ./wp-content/uploads/ user@server:/var/www/eksempel.no/wp-content/uploads/

Fjern n fra -avzn når fillisten ser riktig ut. To detaljer avgjør resultatet. Skråstreken på slutten av kildestien betyr “innholdet i denne katalogen”; uten den ender du med uploads/uploads. Og --delete speiler også slettinger, altså fjerner alt på målet som mangler lokalt. Kjørt fra en utdatert lokal kopi rydder den bort mediebiblioteket i stedet for å synkronisere det. rsync må dessuten finnes i begge ender, og på enkelte delte webhotell er den ikke installert på serveren. Sjekk med ssh user@server 'which rsync' før du bygger en rutine på den.

#9. Hvordan koble til MySQL på serveren via SSH-tunnel

Managed webhotell stenger MySQL mot omverdenen. Port 3306 svarer bare på localhost, skrivebordsklienten går i tidsavbrudd, og i kontrollpanelet sitter du igjen med phpMyAdmin. Du trenger ikke en åpen port, du trenger en tunnel.

#ssh -L

## Koble lokal port 3307 til serverens MySQL, uten å åpne et fjernskall
ssh -N -L 3307:127.0.0.1:3306 user@server

La det terminalvinduet stå åpent og pek TablePlus, DBeaver eller vanlige mysql mot 127.0.0.1:3307. -N betyr “ingen fjernkommando”, økten gjør ingenting annet enn å videresende. Samme grep når alt annet som bare lytter lokalt på serveren: Redis på 6379, en staging-applikasjon på 8080, et endepunkt som aldri var ment å være offentlig. Velg en lokal port som faktisk er ledig, for ssh melder fra om at bindingen feilet og holder likevel økten åpen. Det ser ut som en fungerende tunnel helt til første spørring henger.

#10. Hvordan bytte domene i WordPress med WP-CLI search-replace

Etter en migrering står det gamle domenet fortsatt i databasen, og en god del av det ligger inne i serialiserte PHP-tabeller der hver streng bærer sin egen lengde. Et vanlig UPDATE ... REPLACE bytter teksten og lar lengden bli stående feil, og da kommer widgets, temainnstillinger og page builder-oppsett tilbake tomme. WP-CLI forstår serialisering, og viser deg hva den har tenkt å røre før den rører det.

#wp search-replace --dry-run

## Tell opp hva som ville endret seg, skriv ingenting
wp search-replace 'https://staging.eksempel.no' 'https://eksempel.no' --dry-run --all-tables-with-prefix --report-changed-only

Du får en tabell med antall treff per kolonne. Når tallene stemmer med forventningen, kjører du samme kommando uten --dry-run. Legg til --precise hvis nettstedet har nøstet serialisering, det tvinger den tregere veien gjennom PHP i stedet for snarveien i SQL, og --recurse-objects når serialiserte objekter er involvert. Ta en wp db export først uansett: search-replace har ingen angreknapp.

#Hvordan overvåke CPU, minne og prosesser på serveren

#Ressursbruk i sanntid

# Vis prosessene som bruker mest ressurser på WordPress-serveren
top

# Forbedret versjon (hvis tilgjengelig)
htop

# Vis minnebruk
free -h

# Vis diskbruk per partisjon
df -h

# Vis aktive nettverkstilkoblinger
netstat -tuln

#Hvordan finne tunge PHP-prosesser

# Vis aktive PHP-prosesser
ps aux | grep php

# Vis spørringene MySQL kjører akkurat nå
mysqladmin -u root -p processlist

Disse kommandoene svarer på et annet spørsmål enn diskkommandoene: ikke hva som tar plass, men hva som bruker prosessoren akkurat nå. Når flere PHP-prosesser ligger fast øverst i listen, er synderen nesten aldri WordPress selv, men en treg spørring eller en cron-jobb som overlapper med seg selv fordi forrige kjøring ikke er ferdig. Sjekk den hypotesen med wp cron event list før du rører serveren. Og husk at du på delt webhotell ser prosessene til hele maskinen, så høy last trenger ikke ha noe med ditt nettsted å gjøre.

#Hvordan lage aliaser og vedlikeholdsskript for WordPress

Lag aliaser for kommandoer du bruker ofte:

# Legg til i ~/.bashrc eller ~/.zshrc
alias wplog='tail -f wp-content/debug.log'
alias wpsize='du -h --max-depth=1 | sort -hr'
alias wpcache='rm -rf wp-content/cache/*'
alias wpdb='wp db export backup-$(date +%Y%m%d).sql'
alias wpcheck='wp core verify-checksums && wp plugin list --update=available'

#Automatisk vedlikeholdsskript

#!/bin/bash
# Daglig vedlikeholdsskript for WordPress
echo "=== WordPress-vedlikehold $(date) ==="

# Sikkerhetskopi av databasen
wp db export /backup/db-$(date +%Y%m%d).sql
echo "Databasen er sikkerhetskopiert"

# Kontroller integriteten til kjernen
wp core verify-checksums
echo "Kjernen er kontrollert"

# List opp tilgjengelige oppdateringer
echo "=== Tilgjengelige oppdateringer ==="
wp plugin list --update=available
wp theme list --update=available
wp core check-update

# Slett utløpte transients
wp transient delete --expired
echo "Transients er slettet"

# Optimaliser databasen
wp db optimize
echo "Databasen er optimalisert"

echo "=== Vedlikehold fullført ==="

#Hvordan kjøre WP-CLI på en ekstern server fra din egen maskin

WP-CLI kan kjøre en kommando på en annen maskin over SSH, så du slipper å åpne et skall først. WP-CLI-håndboken beskriver den globale parameteren --ssh i formen [<scheme>:][<user>@]<host>[:<port>][<path>] (Running commands remotely):

wp [email protected]:2222/home/kunde/public_html plugin list

Stien kommer rett etter porten. Oppgir du bare verten, blir brukeren ditt lokale brukernavn, porten 22 og stien hjemmemappen til SSH-brukeren. Et alias fra ~/.ssh/config fungerer også, så wp --ssh=kunde-prod arver port og nøkkel fra avsnittet om den filen. For prosjekter du ofte er innom, registrerer du aliaser i prosjektets wp-cli.yml eller i den globale ~/.wp-cli/config.yml:

@prod:
  ssh: [email protected]/home/kunde/public_html
@staging:
  ssh: [email protected]/home/kunde/staging
@both:
  - @prod
  - @staging

Deretter spør wp @prod core version produksjon, og gruppen @both kjører wp @both core check-update på begge installasjonene i én omgang. Betingelsen de fleste delte webhotell snubler i: WP-CLI må være installert på serveren og tilgjengelig som wp i serverens $PATH. En SSH-økt startet på denne måten leser ikke ~/.bashrc, så en wp du har satt opp som alias der blir ikke funnet. Håndboken anbefaler å legge den kjørbare filen i $HOME/bin/wp. Gjennom linjen din går bare kommandoen og utdataene, og derfor er det så enkelt å kjøre wp search-replace --dry-run fra forrige avsnitt mot et nettsted i drift.

#Hva gjør du når webhotellet bare har SFTP

Enkelte delte pakker selger SSH og leverer SFTP, altså filoverføring over samme protokoll uten et skall bak. Du oppdager det i det øyeblikket ssh user@host 'ls' svarer med exec request failed on channel 0. Ingenting i denne guiden som kjører på serveren overlever det: verken du, tar eller WP-CLI, fordi det ikke finnes noen prosess å kjøre dem i. Overføringslaget virker fortsatt, så sftp flytter filer raskere og tryggere enn en klient med vindu (rsync gjør ikke det, fordi det må starte sin egen prosess på den andre siden), og databasearbeidet flytter tilbake til nettleseren, til phpMyAdmin og en sikkerhetskopiutvidelse. Før du slår deg til ro med det, sjekk om leverandøren tilbyr skall på en annen port eller skrur det på ved henvendelse, for hos flere av dem er dette en innstilling og ikke en produktgrense. Finnes det virkelig ikke i den pakken, har du et konkret argument for å flytte, siden hver eneste arbeidsflyt over er stengt for deg der.

#Oppsummering

SSH-terminalen biter ikke. Den lar deg jobbe med hastigheten til serverdisken, ikke internetthastigheten din. Start med ncdu og tail -f.